DEVOCEAN

4번째 쿠버네티스 스터디를 삼화타워에서 진행했습니다.

드디어 마지막 날이네요. 벌써 8주가 지났습니다. ㅎㅎㅎ

오늘 발표는 이석원님이 해주셨어요.

그리고 다들 저녁을 못먹고 왔으니 간단한 저녁으로 오늘은 서브웨이 샌드위치를 준비했습니다.

역시 데보션에서 지원을 ^^

Master 상세 - etcd(엣지디)

모든 상태와 데이터를 저장

분산 시스템으로 구성하여 안정성을 높임(고가용성)

가볍고 빠르면서 정확하게 설계(일관성))

Key(directory)-Vaule 형태로 데이터 저장

TTL(time to live), watch 같은 부가 기능 제공

백업은 필수!!!

Master 상세 - API server

상태를 바꾸거나 조회

etcd와 유일하게 통신하는 모듈

REST API 형태로 제공

권한을 체크하여 적절한 권한이 없을 경우 요청을 차단

관리자 요청 뿐 아니라 다양한 내부 모듈과 통신

수평으로 확장되도록 디자인

Master 상세 - Scheduler

새로 생성된 Pod을 감지하고 실행할 노드를 선택

노드의 현재 상태와 Pod의 요구사항을 체크

노드에 라벨을 부여

ex) a-zone, b-zone 또는 gpu-enabled, ...

Master 상세 - Controller

논리적으로 다양한 컨트롤러가 존재

복제 컨트롤러

노드 컨트롤러

엔드포인트 컨트롤러 ...

끊임 없이 상태를 체크하고 원하는 상태를 유지

복잡성을 낮추기 위해 하나의 프로세스로 실행

Master 상세 - 조회흐름

Node 상세 - kubelet

컨테이너 관리 확실하게

각 노드에서 실행

Pod을 실행/중지하고 상태를 체크

CRI(Container Runtime Interface)

docker

Containerd

CRI-O

...

Node 상세 - proxy

내/외부로 통신 설정하기

네트워크 프록시와 부하 분산 역할

성능상의 이유로 별도의 프록시 프로그램 대신 iptables 또는 IPVS를 사용 (설정만 관리)

kubernetes에서 pod 생성을 요청하였을때 내부에서 어떤 일들이 벌어지는가?

from: Core Kubernetes: Jazz Improv over Orchestration

1. kubectl은 API Server에 Pod생성을 요청

2. APIServer는 etcd에 Node에 할당되지 않은 Pod이 있음을 업데이트

3. Scheduler는 etcd의 변경사항을 API Server를 통해 watch하고 Pod을 실행할 Node를 선택해 API Server에 해당 Node에 Pod을 배정하도록 업데이트

4. 해당 Node의 Kubelet은 생성할 Pod정보를 watch해서 Docker 컨테이너를 실행하고 결과를 API Server에 지속적으로 업데이트

5. API Server는 전달받은 Pod의 상태를 etcd에 업데이트

Kubernetes에서 Pod 생성 요청이 발생하면, 내부에서는 여러 단계를 거쳐 Pod가 배포되고 실행됩니다.

주요 단계는 다음과 같습니다:

• 요청 처리: 사용자는 kubectl 명령어를 사용하거나, Kubernetes API를 통해 Pod 생성 요청을 보냅니다. 요청이 수신되면, 유효성 검사가 이루어집니다.

• API 서버: 유효성 검사 후, API 서버는 요청을 처리하고 etcd에 저장합니다. etcd는 분산 데이터 저장소로, Kubernetes 클러스터의 모든 데이터와 상태 정보를 저장합니다.

• 컨트롤러 관리자(Control Manager): etcd에서 변경 사항을 감지한 컨트롤러 관리자는 새로운 Pod를 생성하고 관리하기 위한 적절한 동작을 수행합니다.

• 스케줄러: 새로운 Pod가 생성되면, 아직 노드에 할당되지 않은 상태입니다. Kubernetes 스케줄러는 클러스터 내의 사용 가능한 노드를 검사하여 적절한 노드를 선택하고 Pod를 배치합니다.

  스케줄러는 리소스 요구 사항, 노드 제약 조건, 어피니티 및 안티-어피니티 규칙 등을 고려하여 노드를 선택합니다.

• Kubelet: 선택된 노드의 Kubelet은 Pod를 실행하기 위해 필요한 컨테이너를 생성하고, 실행하며, 모니터링합니다. Kubelet은 컨테이너 런타임(예: Docker, containerd 등)을 사용하여 컨테이너를 실행합니다.

• 컨테이너 런타임: 컨테이너 런타임은 이미지를 가져와서 컨테이너를 생성하고, 실행하며, 상태를 모니터링하고 필요에 따라 로그를 수집합니다.

• 서비스 프록시: 필요한 경우, 서비스 프록시(kube-proxy)는 Pod 간 통신을 가능하게 하는 서비스를 설정하고 관리합니다.

이러한 단계를 거쳐 새로운 Pod가 생성되어 실행되며, Kubernetes 클러스터에서 관리됩니다.

사용자는 kubectl 명령어를 사용하여 Pod의 상태를 확인하거나, 로그를 검색하거나, 클러스터 내에서 실행 중인 다른 리소스와 상호 작용할 수 있습니다.

리소스 할당량(resource quota)은 애플리케이션이 사용할 수 있는 CPU 또는 메모리 양을 제어하여 리소스 경합 및 '랜드 그랩(토지수탈?)'을 방지합니다.

리소스 할당량(resource quota)이란?

간단히 말해 리소스 할당량(resource quota)은 네임스페이스당 리소스 사용을 제한하는 제약 조건을 제공합니다.

네임스페이스 수준에서만 적용될 수 있으므로 컴퓨팅 리소스에 적용하여 네임스페이스 내의 개체 수를 제한할 수 있다.

쿠버네티스 리소스 할당량은 리소스쿼터(ResourceQuota) 오브젝트에 의해 정의된다.

네임스페이스에 적용하면 CPU 및 메모리와 같은 컴퓨팅 리소스는 물론 다음 오브젝트의 생성을 제한할 수 있다:

• Pods

• Services

• Secrets

• Persistent Volume Claims (PVCs)

• ConfigMaps

쿠버네티스는 컴퓨팅 리소스를 관리하기 위해 두 가지 유형의 CPU 및 메모리 쿼터를 지원한다. 이는 리밋레인지 문서에서 설명하는 것처럼 리밋과 요청을 통해 제어된다.

간단히 말해, 요청(request)은 컨테이너에 대해 보장된 CPU 또는 메모리 리소스를 정의하는 반면, 제한(limit)은 다른 컨테이너의 사용량에 따라 컨테이너가 사용할 수 있는 메모리 또는 CPU 임계값을 의미합니다.

아래 이미지는 쿠버네티스 리소스 쿼터에서 요청과 제한의 차이를 보여줍니다.

Kubernetes resource quota에서 request와 limit의 차이

리소스 할당량(resource quota) 예제

CPU quota를 적용할 namespace 생성

quota-test namespace 생성

$ kubectl create namespace quota-test

namespace/quota-test created

cpu-quota.yaml 파일 작성

apiVersion: v1

kind: ResourceQuota

metadata:

name: test-cpu-quota

** namespace: quota-test

**spec:

hard:

requests.cpu: "100m"limits.cpu: "200m"

cpu-quota.yaml Kubernetes cluster에 적용

$ kubectl apply -f cpu-qouta.yaml

resourcequota/test-cpu-quota created

kubectl describe command로 확인

$ kubectl describe resourcequota/test-cpu-quota --namespace quota-test

Name: test-cpu-quota

Namespace: quota-test

Resource Used Hard

limits.cpu 0 200m

requests.cpu 0 100m

Test

이제 할당량을 정의했으니 테스트. 이 예제에서는 동일한 네임스페이스에 서로 다른 세 개의 파드를 배포하여 정의한 제한에 따라 리소스 사용량을 제어할 수 있는지 확인.

세 개의 파드는 다음과 같습니다:

• PodA: 가장 먼저 인스턴스화되는 이 파드는 사용 가능한 CPU의 50%를 사용.

• PodB: 이 파드는 사용 가능한 CPU의 나머지 50%를 사용하며, 두 번째로 인스턴스화된 파드이다.

• 파드C: 정의된 할당량으로 인해 이 세 번째 파드가 배포되지 않아야 한다.

poda 생성됨

$ kubectl create -n quota-test -f- <<EOF

apiVersion: v1

kind: Pod

metadata:

name: poda

spec:

containers:

• name: quota-test

  image: busybox

  imagePullPolicy: IfNotPresent

  command: ['sh', '-c', 'echo Pod is Running ; sleep 5000']

  resources:

  requests:

  cpu: "50m"

  limits:

  cpu: "100m"

  restartPolicy: Never

  EOF

  pod/poda created

  podb 생성됨

  $ kubectl describe resourcequota/test-cpu-quota --namespace quota-test

  Name: test-cpu-quota

  Namespace: quota-test

  Resource Used Hard

limits.cpu 100m 200m

requests.cpu 50m 100m

[root@k8s-master qouta]# kubectl create -n quota-test -f- <<EOF

apiVersion: v1

kind: Pod

metadata:

name: podb

spec:

containers:

• name: quota-test

  image: busybox

  imagePullPolicy: IfNotPresent

  command: ['sh', '-c', 'echo Pod is Running ; sleep 5000']

  resources:

  requests:

  cpu: "50m"

  limits:

  cpu: "100m"

  restartPolicy: Never

  EOF

  pod/podb created

  quota 사용량 확인, Hard Limit까지 사용중

  $ kubectl describe resourcequota/test-cpu-quota --namespace quota-test

  Name: test-cpu-quota

  Namespace: quota-test

  Resource Used Hard

limits.cpu 200m 200m

requests.cpu 100m 100mpodc 생성요청

$ kubectl describe resourcequota/test-cpu-quota --namespace quota-test

Name: test-cpu-quota

Namespace: quota-test

Resource Used Hard

limits.cpu 200m 200m

requests.cpu 100m 100m

[root@k8s-master qouta]# kubectl create -n quota-test -f- <<EOF

apiVersion: v1

kind: Pod

metadata:

name: podc

spec:

containers:

• name: quota-test

  image: busybox

  imagePullPolicy: IfNotPresent

  command: ['sh', '-c', 'echo Pod is Running ; sleep 5000']

  resources:

  requests:

  cpu: "5m"

  limits:

  cpu: "10m"

  restartPolicy: Never

  EOF

  Error from server (Forbidden): error when creating "STDIN": pods "podc" is forbidden: exceeded quota: test-cpu-quota, requested: limits.cpu=10m,requests.cpu=5m, used: limits.cpu=200m,requests.cpu=100m, limited: limits.cpu=200m,requests.cpu=100m

  🥕Quota를 초과하는 리소스를 사용하려하여 Pod 생성이 안된다는 메시지 출력

Error from server (Forbidden): error when creating "STDIN": pods "podc" is forbidden: exceeded quota: test-cpu-quota, requested: limits.cpu=10m,requests.cpu=5m, used: limits.cpu=200m,requests.cpu=100m, limited: limits.cpu=200m,requests.cpu=100m

Clean up

$ kubectl delete -n quota-test

Kubernetes 스케줄러가 새 파드를 발견하고 노드에 할당하는 방법에 대해

How Kubernetes scheduler works

쿠버네티스 파드는 공유 스토리지 및 네트워크 리소스가 있는 하나 이상의 컨테이너로 구성. Kubernetes 스케줄러의 임무는 각 파드가 실행할 노드에 할당되도록 하는 것입니다.

개략적인 수준에서 Kubernetes 스케줄러의 작동 원리는 다음과 같습니다:

1. 예약해야 하는 모든 파드가 큐에 추가됩니다.

2. 새 파드가 생성되면, 해당 파드도 큐에 추가된다.

3. 스케줄러는 해당 큐에서 지속적으로 파드를 가져와 스케줄링한다.

스케줄러의 코드 scheduler.go는 약 9,000줄에 달하는 방대한 분량이며 상당히 복잡하지만, 중요한 부분은 다음과 같다:

1. Code that waits/watches for pod creation

   // Run begins watching and scheduling. It waits for cache to be synced, then starts a goroutine and returns immediately.

func (sched *Scheduler) Run() {

if !sched.config.WaitForCacheSync() {

return

}

go wait.Until(sched.scheduleOne, 0, sched.config.StopEverything)

이 코드는 Kubernetes에서 사용되는 스케줄러(Scheduler)의 Run 메서드입니다.

이 메서드는 스케줄링을 시작하는 함수이며, 캐시 동기화를 대기하고 goroutine을 시작합니다.

먼저 WaitForCacheSync 메서드를 사용하여 스케줄러의 캐시 동기화가 완료될 때까지 기다립니다. 캐시가 동기화되면, 스케줄러의 scheduleOne 메서드를 실행하는 goroutine을 시작합니다.

wait.Until 함수는 주어진 함수(scheduleOne)를 반복적으로 실행합니다. 이 함수는 스케줄러가 파드를 하나씩 가져와서 해당 파드를 실행할 수 있는 적절한 노드를 찾아 할당하는 역할을 수행합니다.

마지막으로, sched.config.StopEverything 채널이 닫히면 스케줄러가 중지됩니다.

즉, 이 코드는 스케줄러가 파드를 스케줄링하기 위해 goroutine을 시작하고, 캐시 동기화를 기다린 후 scheduleOne 메서드를 주기적으로 실행하여 파드를 노드에 할당하는 역할을 합니다.

2. Code that is responsible for queuing the pod

   파드 큐잉을 담당하는 함수는 다음과 같다:

// queue for pods that need scheduling

podQueue *cache.FIFO

이벤트 핸들러가 트리거되어 새 파드를 사용할 수 있음을 나타내면 이 코드가 자동으로 새 파드를 큐에 넣습니다:

func (f *ConfigFactory) getNextPod() *v1.Pod {

for {

pod := cache.Pop(f.podQueue).(*v1.Pod)

if f.ResponsibleForPod(pod) {

glog.V(4).Infof("About to try and schedule pod %v", pod.Name)

return pod

}

}

}

이 코드는 Kubernetes의 스케줄러에서 사용되는 ConfigFactory 타입의 메서드인 getNextPod입니다.

이 메서드는 스케줄러에서 처리할 다음 파드를 가져오는 함수입니다.

코드에서는 cache.Pop 함수를 사용하여 파드 큐에서 다음 파드를 가져옵니다. 가져온 파드는 *v1.Pod 형태로 반환되며, 이를 pod 변수에 할당합니다.

ResponsibleForPod 함수를 사용하여 해당 파드가 현재 스케줄러에 의해 스케줄링될 수 있는지 확인합니다.

만약 해당 파드가 스케줄러에 의해 스케줄링될 수 있다면, pod 변수를 반환하고, 그렇지 않으면 다음 파드를 가져오기 위해 반복문을 계속 실행합니다.

코드에서는 로그를 남기기 위해 glog.V(4) 함수를 사용하여 로그 레벨을 설정하고, "About to try and schedule pod [파드 이름]"이라는 메시지를 로그로 출력합니다.

따라서 이 코드는 파드 큐에서 다음 스케줄링할 파드를 가져오고, 이를 스케줄러에 의해 스케줄링할 수 있는지 확인한 후 해당 파드를 반환하는 역할을 합니다.

3. Code that handles errors

   파드 스케줄링에서 스케줄링 오류가 필연적으로 발생할 수 있다. 다음 코드는 스케줄러가 에러를 처리하는 방법이다. 이 스케줄러는 podInformer를 수신한 다음, 파드가 스케줄링되지 않았다는 오류를 출력하고 종료한다:

// scheduled pod cache

podInformer.Informer().AddEventHandler(

cache.FilteringResourceEventHandler{

FilterFunc: func(obj interface{}) bool {

switch t := obj.(type) {

case *v1.Pod:

return assignedNonTerminatedPod(t)

default:

runtime.HandleError(fmt.Errorf("unable to handle object in %T: %T", c, obj))

return false

}

},

이 코드는 Kubernetes 스케줄러에서 사용되는 이벤트 핸들러 함수입니다. 이벤트 핸들러 함수는 캐시에 저장된 오브젝트의 변경 사항을 감지하고, 변경 사항이 발생할 때마다 실행됩니다.

podInformer는 파드에 대한 informer입니다. informer는 Kubernetes에서 객체의 변경 사항을 감지하고, 변경 사항을 핸들러 함수로 전달합니다.

AddEventHandler 함수는 파드 informer에 대한 이벤트 핸들러를 등록하는 함수입니다.

이벤트 핸들러로는 cache.FilteringResourceEventHandler를 사용하며, 이벤트 발생 시 필터링 및 처리할 리소스 유형과 관련된 함수를 제공합니다.

이 코드에서는 FilterFunc 함수를 사용하여 파드를 필터링하고, assignedNonTerminatedPod 함수를 사용하여 조건을 검사합니다.

assignedNonTerminatedPod 함수는 스케줄러가 할당된 파드를 검사하고, 아직 종료되지 않은 파드만을 대상으로 합니다.

만약 필터링 결과가 true이면 이벤트 핸들러 함수를 실행하고, false이면 실행하지 않습니다.

이 코드는 파드 informer에 대한 이벤트 핸들러를 등록하고, 필터링 조건에 따라 파드 객체의 변경 사항을 처리합니다.

즉, 쿠버네티스 스케줄러가 담당하는 업무들은 :

파드의 리소스 요구를 충족시키기에 충분한 공간을 가진 노드에서 새로 생성된 파드를 스케줄링한다.

새로 생성된 파드의 존재를 위해 kube-apiserver와 컨트롤러를 수신한 다음 클러스터의 사용 가능한 노드로 스케줄링한다.

스케줄되지 않은 파드를 감시하고 /binding pod 하위 리소스 API를 사용하여 노드에 바인딩한다.

예를 들어, 1GB의 메모리와 2개의 CPU 코어가 필요한 애플리케이션이 배포되고 있다고 가정해 보자.

따라서 이 애플리케이션의 파드는 사용 가능한 리소스가 충분한 노드에 생성됩니다. 그런 다음 스케줄러가 계속 실행되면서 스케줄링해야 하는 파드가 있는지 확인합니다.

Extending Kubernetes

Extension points

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

API 서버는 모든 요청을 처리한다. API 서버의 여러 유형의 확장 포인트는 요청을 인증하거나, 요청의 내용에 따라 요청을 차단하고, 콘텐츠를 편집하고, 삭제를 처리할 수 있다.

이들은 API 액세스 확장 섹션에 설명되어 있다.

API 서버는 다양한 종류의 리소스를 제공합니다.

파드와 같은 기본 제공 리소스 종류는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없습니다.

쿠버네티스 API 확장에 대해 알아보려면 API 확장을 읽어본다.

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

쿠버네티스의 대부분의 동작은 API 서버의 클라이언트인 컨트롤러라고 하는 프로그램에 의해 구현된다.

컨트롤러는 종종 커스텀 리소스와 함께 사용된다.

자세한 내용은 새 API와 자동화 결합하기 및 기본 제공 리소스 변경하기를 읽어본다.

kubelet은 서버(노드)에서 실행되며, 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 도와준다.

네트워크 플러그인을 사용하면 파드 네트워킹을 다양하게 구현할 수 있다.

디바이스 플러그인을 사용하여 사용자 정의 하드웨어 또는 기타 특수 노드-로컬 시설을 통합하고 클러스터에서 실행 중인 파드에서 이를 사용할 수 있도록 할 수 있다.

쿠블릿은 디바이스 플러그인 작업에 대한 지원을 포함한다.

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

Extension point choice flowchart

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