Extending Kubernetes

Winston Lee·2023년 5월 9일
k8s
0

k8s

목록 보기
6/9

Extending Kubernetes에 대해서 정리

Extending Kubernetes

Extension points
Extension points

  1. 사용자는 종종 kubectl을 사용하여 쿠버네티스 API와 상호작용한다. 플러그인은 클라이언트의 동작을 사용자 정의한다. 다양한 클라이언트에 적용할 수 있는 일반적인 확장과 kubectl을 확장하는 특정 방법이 있다.

  2. API 서버는 모든 요청을 처리한다. API 서버의 여러 유형의 확장 포인트는 요청을 인증하거나, 요청의 내용에 따라 요청을 차단하고, 콘텐츠를 편집하고, 삭제를 처리할 수 있다. 이들은 API 액세스 확장 섹션에 설명되어 있다.

  3. API 서버는 다양한 종류의 리소스를 제공합니다. 파드와 같은 기본 제공 리소스 종류는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없습니다. 쿠버네티스 API 확장에 대해 알아보려면 API 확장을 읽어본다.

  4. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 방법에는 여러 가지가 있으며, 스케줄링 확장 섹션에 설명되어 있다.

  5. 쿠버네티스의 대부분의 동작은 API 서버의 클라이언트인 컨트롤러라고 하는 프로그램에 의해 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다. 자세한 내용은 새 API와 자동화 결합하기 및 기본 제공 리소스 변경하기를 읽어본다.

  6. kubelet은 서버(노드)에서 실행되며, 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 도와준다. 네트워크 플러그인을 사용하면 파드 네트워킹을 다양하게 구현할 수 있다.

  7. 디바이스 플러그인을 사용하여 사용자 정의 하드웨어 또는 기타 특수 노드-로컬 시설을 통합하고 클러스터에서 실행 중인 파드에서 이를 사용할 수 있도록 할 수 있다. 쿠블릿은 디바이스 플러그인 작업에 대한 지원을 포함한다.

또한, 쿠블릿은 파드와 해당 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 스토리지 플러그인을 사용하여 새로운 종류의 스토리지 및 기타 볼륨 유형에 대한 지원을 추가할 수 있다.

Extension point choice flowchart
Extension point choice flowchart

Client extensions

Extend kubectl with plugins 참조

API extensions

  • Custom resource definitions
  • API aggregation layer
  • Combining new APIs with automation
  • Changing built-in resources

API access extensions

API 사용을 위한 Kubernetes 인증/권한 부여 흐름의 각 단계는 확장 지점을 제공

  • Authentication (인증)
  • Authorization (권한 부여)
  • Dynamic admission control(동적 승인 제어)

Infrastructure extensions

  • Device plugins
  • Storage plugins
    Container Storage Interface (CSI)
  • Network plugins
    Kubernetes가 다양한 네트워킹 토폴로지 및 기술과 함께 작동

Scheduling extensions

스케줄러는 포드를 감시하고 포드를 노드에 할당하는 특수한 유형의 컨트롤러
기본 스케줄러를 완전히 교체하거나 여러 스케줄러를 동시에 실행할 수 있지만,
필요성은 못 느낌.

Compute, Storage, and Networking Extensions

Kubernetes가 제공하지 않는 클러스터 확장에 대한 설명. 이러한 확장을 사용하여 클러스터의 노드를 향상시키거나 포드를 함께 연결하는 네트워크 패브릭을 제공할 수 있다

  • CSI and FlexVolume storage plugins
    컨테이너 스토리지 인터페이스(CSI) 플러그인은 새로운 종류의 볼륨을 지원하여 Kubernetes를 확장하는 방법을 제공
  • Device plugins
    cpu장치 플러그인을 사용하면 노드가 새 노드 기능( 및 과 같은 기본 제공 노드 리소스 외에 memory)을 검색하고 이를 요청하는 Pod에 이러한 사용자 지정 노드-로컬 기능을 제공, GPU도...
  • Network plugins
    Kubernetes 클러스터는 Pod 네트워크가 작동하고 Kubernetes 네트워크 모델의 다른 측면을 지원하기 위해 네트워크 플러그인이 필요

Network Plugins

쿠버네티스 1.27 버전은 클러스터 네트워킹을 위해 컨테이너 네트워크 인터페이스(CNI) 플러그인을 지원한다. 클러스터와 호환되며 사용자의 요구 사항을 충족하는 CNI 플러그인을 사용해야 한다. 더 넓은 쿠버네티스 생태계에 다양한 플러그인이 존재한다(오픈소스 및 클로즈드 소스).

CNI 플러그인은 쿠버네티스 네트워크 모델을 구현해야 한다.

v0.4.0 이상의 CNI 스펙과 호환되는 CNI 플러그인을 사용해야 한다. 쿠버네티스 플러그인은 CNI 스펙 v1.0.0과 호환되는 플러그인의 사용을 권장한다(플러그인은 여러 스펙 버전과 호환 가능)

Device Plugins

다음은 장치 플러그인 구현의 예이다.

  • AMD GPU 장치 플러그인
  • 인텔 GPU, FPGA, QAT, VPU, SGX, DSA, DLB 및 IAA 장치용 인텔 장치 플러그인
  • 하드웨어 지원 가상화를 위한 KubeVirt 장치 플러그인
  • 컨테이너에 최적화된 OS를 위한 NVIDIA GPU 장치 플러그인
  • RDMA 장치 플러그인
  • SocketCAN 장치 플러그인
  • Solarflare 장치 플러그인
  • SR-IOV 네트워크 장치 플러그인
  • Xilinx FPGA 장치용 Xilinx FPGA 장치 플러그인

Extending the Kubernetes API

Custom Resources

커스텀 리소스는 쿠버네티스 API의 확장이다. 언제 쿠버네티스 클러스터에 사용자 정의 리소스를 추가해야 하는지, 언제 독립형 서비스를 사용해야 하는지에 대해 설명한다. 사용자 정의 리소스를 추가하는 두 가지 방법과 그 중에서 선택하는 방법에 대해 설명한다.

  • Custom resources
    리소스는 특정 종류의 API 오브젝트 컬렉션을 저장하는 Kubernetes API의 엔드포인트로, 예를 들어 기본 제공 파드 리소스에는 파드 오브젝트 컬렉션이 포함되어 있습니다.

    사용자 정의 리소스는 기본 쿠버네티스 설치에서 반드시 사용할 수 있는 것은 아닌 쿠버네티스 API의 확장이다. 이것은 특정 쿠버네티스 설치의 커스터마이징을 나타낸다. 그러나 이제 많은 핵심 쿠버네티스 기능이 사용자 정의 리소스를 사용하여 구축되어 쿠버네티스를 더욱 모듈화한다.

    사용자 정의 리소스는 동적 등록을 통해 실행 중인 클러스터에 나타나거나 사라질 수 있으며, 클러스터 관리자는 클러스터 자체와 독립적으로 사용자 정의 리소스를 업데이트할 수 있습니다. 커스텀 리소스가 설치되면 사용자는 파드와 같은 기본 제공 리소스와 마찬가지로 kubectl을 사용하여 해당 오브젝트를 생성하고 액세스할 수 있다.

  • Custom controllers
    사용자 정의 리소스를 단독으로 사용하면 구조화된 데이터를 저장하고 검색할 수 있습니다. 사용자 지정 리소스를 사용자 지정 컨트롤러와 결합하면 사용자 지정 리소스가 진정한 선언적 API를 제공합니다.

    쿠버네티스 선언적 API는 책임 분리를 시행한다. 사용자는 리소스의 원하는 상태를 선언한다. 쿠버네티스 컨트롤러는 쿠버네티스 오브젝트의 현재 상태를 사용자가 선언한 원하는 상태와 동기화하여 유지한다. 이는 서버에 수행해야 할 작업을 지시하는 명령형 API와는 대조적입니다.

    클러스터의 라이프사이클과 무관하게 실행 중인 클러스터에 사용자 정의 컨트롤러를 배포하고 업데이트할 수 있다. 사용자 지정 컨트롤러는 모든 종류의 리소스와 함께 작동할 수 있지만 특히 사용자 지정 리소스와 결합할 때 효과적입니다. 오퍼레이터 패턴은 사용자 지정 리소스와 사용자 지정 컨트롤러를 결합합니다. 커스텀 컨트롤러를 사용하여 특정 애플리케이션에 대한 도메인 지식을 쿠버네티스 API의 확장으로 인코딩할 수 있다.

Kubernetes API Aggregation Layer

skip

Operator pattern

오퍼레이터는 애플리케이션과 그 구성 요소를 관리하기 위해 사용자 정의 리소스를 사용하는 쿠버네티스의 소프트웨어 확장이다. 오퍼레이터는 쿠버네티스 원칙, 특히 제어 루프를 따릅니다.

Operators in Kubernetes

Kubernetes를 사용하여 워크로드 배포 및 실행을 자동화할 수 있으며, Kubernetes가 이를 수행하는 방법도 자동화할 수 있습니다.

쿠버네티스의 오퍼레이터 패턴 개념을 사용하면 컨트롤러를 하나 이상의 사용자 정의 리소스에 연결하여 쿠버네티스 자체의 코드를 수정하지 않고도 클러스터의 동작을 확장할 수 있습니다. 오퍼레이터는 커스텀 리소스에 대한 컨트롤러 역할을 하는 쿠버네티스 API의 클라이언트이다.

An example operator
  • 온디맨드 애플리케이션 배포
  • 해당 애플리케이션 상태의 백업 생성 및 복원
  • 데이터베이스 스키마 또는 추가 구성 설정과 같은 관련 변경 사항과 함께 애플리케이션 코드의 업그레이드 처리
  • 쿠버네티스 API를 지원하지 않는 애플리케이션에 서비스를 퍼블리시하여 이를 발견하기 위한 작업
  • 클러스터의 전체 또는 일부에서 장애를 시뮬레이션하여 복원력 테스트하기
  • 내부 멤버 선출 프로세스 없이 분산 애플리케이션의 리더 선택
Deploying operators

운영자를 배포하는 가장 일반적인 방법은 사용자 정의 리소스 정의 및 관련 컨트롤러를 클러스터에 추가하는 것
컨트롤러는 일반적으로 컨테이너화된 애플리케이션을 실행할 때와 마찬가지로 컨트롤 플레인 외부에서 실행됩니다. 예를 들어 클러스터에서 컨트롤러를 배포로 실행할 수 있습니다

Using an operator

operator를 배포 후 사용하면 운영자가 사용하는 리소스의 종류를 추가, 수정 또는 삭제하여 사용할 수 있습니다.

kubectl get SampleDB                   # find configured databases

kubectl edit SampleDB/example-database # manually change some settings
Writing your own operator

원하는 동작을 구현하는 운영자가 에코시스템에 없는 경우 직접 개발할 수 있습니다.

또한 쿠버네티스 API의 클라이언트 역할을 할 수 있는 모든 언어/런타임을 사용하여 오퍼레이터(즉, 컨트롤러)를 구현할 수도 있습니다.

다음은 자체 클라우드 네이티브 오퍼레이터를 작성하는 데 사용할 수 있는 몇 가지 라이브러리 및 도구입니다.

  • Charmed Operator Framework
  • Java Operator SDK
  • Kopf (Kubernetes Operator Pythonic Framework)
  • kube-rs (Rust)
  • kubebuilder
  • KubeOps (.NET operator SDK)
  • KUDO (Kubernetes Universal Declarative Operator)
  • Mast
  • Metacontroller along with WebHooks that you implement yourself
  • Operator Framework
  • shell-operator
profile
Winston Lee
인프라 엔지니어
이전 포스트

Kubernetes scheduler 동작

다음 포스트

Scheduling, Preemption and Eviction

0개의 댓글