[Kubernetes] Controller 와 Operator, 어디까지 까봤니?

 

 

틀린 부분이 있을 수 있습니다. 만약 있다면 지적해주세요 :)

 

 

쿠버네티스에서 ReplicaSet 을 통해 3개의 파드를 배포했다고 생각해봅시다. 이때 하나의 파드를 삭제하게 되면 곧 다시 파드가 생성됩니다. 즉, 파드가 최소 3개 이상이 실행되도록 ReplicaSet 를 배포했기 때문에 죽었던 파드를 새롭게 소생시킵니다. 이는 쿠버네티스의 특징 중 하나인 Self Healing 이기도 합니다.

ReplicaSet, Deployment 등에서 명시하는 Replica 의 갯수는 고정/최대가 아닌 최소를 의미합니다.
3개라고 가정했을 때, 롤링업데이트나 비자발적인 종료에 의해 3개 이상의 파드가 존재할 수 있기 때문이죠.

 

그럼 이걸 좀 더 전문적?으로 접근해봅시다.

 

우리가 원했던(Desired) ReplicaSet 의 갯수는 3개입니다. 그런데 하나가 죽어 2개가 되었다(Lived)는 것은 이를 위반하는 행위입니다. 다시 말해 Desired State 와 Lived State 가 다르다는 것이죠.

 

그리고 이러한 위반 사항이 있는지 늘 주시(Watch) 하고 있는 녀석이 있는데, 바로 컨트롤 플레인의 컴포넌트 중 하나인 Controller Manager 입니다.

 

Controller Manager 은 Control Loop 이라는 행위를 통해 우리가 원하는(Desired) 상태와 현재(Lived) 상태를 맞쳐줍니다.

그리고 이렇게 상태를 맞춰주는 행위를 Reconciliation(리컨실리에이션) 이라고 합니다.

 

도식화해보면 아래와 같죠.

https://developers.redhat.com/articles/2021/06/22/kubernetes-operators-101-part-2-how-operators-work

 

Controller Manager 안에선 Control Loop 을 통해 무한히 관련한 리소스를 주시(Watch) 하고 있고, 만약 차이를 보이는 리소스가 있다면 Reconcile(리컨사일) 을 통해서 서로의 상태를 맞쳐줍니다.

 

ReplicaSet 의 매니페스트를 항상 주시하고 있다가, 파드가 하나 죽는다 등의 이벤트가 발생하면 원하는(Desired) 상태로 매니페스트를 맞쳐주는 것이지요.

ReplicaSet 외에도 Deployment, DaemonSet, StatefulSet, CronJob, SeviceAccount 가 Controller Manager 에 의해 주시(Watch) 를 당합니다.

 

한편, Reconciliation 는 3단계로 나눌 수 있습니다.

1. Observe (관찰)
2. Analyze (분석)
3. Act (실행)

관찰(Observe) 하고 있는 리소스의 상태가 변경될 때 Controller Manager 는 관련한 이벤트를 주시(Watch) 하여 실제 상태(Lived State) 를 찾아, 원하는 상태(Desired State) 의 차이를 분석(Analyze) 하고, 원하는 상태로 구동되도록 작업을 수행(Act) 합니다.

관측 -> 분석 -> 실행

"내가 돌아왔다!" 라고 표현하긴 했는데, 정확히는 죽었던 애가 살아나는건 아니고 새롭게 파드를 만든 후에 Deployment 에 맵핑하는 것입니다!

 

이런 행위를 해주는 녀석을 Controller 라고 지칭하는데, 이와 비슷한 행위를 하는 녀석이 하나 더 존재합니다.

바로 오퍼레이터(Operator) 입니다.

 

대표적으로 프로메테우스 오퍼레이터가 존재하죠!

 

사실 이 두 녀석의 행위가 굉장히 비슷하기 때문에 명확하게 둘의 차이를 설명하긴 힘들지만, 보통 CRD(CustomResourceDefinition) 를 통해 Reconciliation 를 수행한다면 Operator, CRD 없이 쿠버네티스 리소스로만 진행되는 Reconciliation 라면 Controller 라고 부릅니다.

 

https://youtu.be/abHOcr-HTI4?si=af9bjsnO2xc5aBNg

 

그런데 이것도 애매한 것이 ArgoCD 를 빗대어 보면 CRD 를 통한 Reconciliation 을 진행하는 컴포넌트의 이름에 Controller 가 붙는다는 것이죠. ArgoCD 또한 Application 같은 CRD 를 사용하는데도 불구하고 말이죠.

 

그렇게 구분 지으려고 노력?하지는 않는거 같습니다.

 

그래도 차이가 더 세부적으로 궁금하다면 여기 Overstackflow 답변을 참고하시면 좋을 거 같습니다.

 

Controller 와 Operator 비교

 

그럼 이제 Controller 와 Operator 가 뭔지 알았으니, 실제로 Controller 를 구현해보죠!

 

To The Code~

 

 

 

나만의 Controller 만들기

---

ConfigMap 이 변경될 경우, Annotations 의 명시된 Deployment 의 파드들을 Recreate 하는 Controller 를 만들어 보겠습니다!

 

myconfig.yaml

apiVersion: v1
data:
  HELLO: "World Twice"
kind: ConfigMap
metadata:
  name: myconfig
  annotations:
    restart-deployment: mypod #-- 파드의 Recreate 를 진행할 Deployment 의 이름

 

mypod.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mypod
  labels:
    app: mypod
    test: test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mypod
  template:
    metadata:
      labels:
        app: mypod
    spec:
      containers:
        - name: mypod
          image: nginx:1.26
          ports:
            - containerPort: 80
          env:
            - name: HELLO
              valueFrom:
                configMapKeyRef:
                  name: myconfig
                  key: HELLO

 

 

코드는 Go 를 통해서 구현했고, kubernetes/client-go 의 examples 를 토대로 만들었습니다.

 

우선 결과부터 보여드리죠!

 

아래 명령어를 통해 Controller 를 실행합니다.

$ go run main.go -kubeconfig="myconfig" -master="myk8surl"

Controller Init

 

그리고 현재 배포되어있는 Deployment 의 Pod 에는 myconfig 가 가지고 있던 데이터값을 환경변수로 들고 있습니다.

Hello=World Twice

 

그럼 이제 myconfig 의 데이터값을 HELLO=World Once 로 바꿔줍니다.

 

그러자 Controller 에서 Sync/Add/Update for ConfigMap myconfig 로그가 하나 더 찍힌걸 확인할 수 있죠.

Sync/Add/Update for ConfigMap myconfig 하나가 더 찍힘

 

또한 k get configmap -w 와 결과가 동일하다는 것을 확인할 수 있습니다.

k get configmap -w

 

그리고 실제로 수동으로 파드를 재시작하지 않고, 자동으로 변경되었는지 확인해봅니다.

Hello=World Once

 

잘 바뀐 것을 확인해볼 수 있습니다!

 

결과를 확인해봤으니, 이제 코드를 한번씩 살펴보겠습니다!

위에 빨간 네모부터 1,2,3 ... 씩 순서를 가집니다!

 

main.go 199

1. ListWatch 객체를 생성합니다, 이 녀석은 뒤에 있을 Informer 에 필요합니다.
2. WorkQueue 객체를 생성합니다, 뒤에 있을 Informer 에 필요합니다.

 

main.go 208

1. Indexer 와 Informer 를 생성합니다.
2. 우리가 만드는 Controller 의 객체를 생성합니다.

Indexer 는 쿠버네티스 리소스의 인덱싱과 빠른 조회를 지원하는 역할을 수행하는데, 이를 통해 조건에 맞는 리소스를 빠르게 찾을 수 있습니다.

 

Informer 는 Controller 를 구현하는데 필요한 핵심 객체 중 하나로, ListWatch 를 통해 우리가 원하는 리소스의 상태를 주시(Watch) 합니다. Add/Update/Delete 이벤트에 대해 반응하여 알려주는(Inform) 녀석입니다.

 

코드를 보면 실제로 Add/Update/Delete 이벤트에 대한 코드를 구현하고 있습니다.

 

또한 Add/Update/Delete 이벤트 안을 보면 queue.Add(key) 를 가지고 있는데, 이를 통해 어떤 리소스인지 알 수 있는 key 를 queue 에 집어넣고, 뒤쪽에 있을 코드에서 pop() 해서 가져오게 됩니다. (뒤쪽에서 다룹니다!)

 

즉, ListWatch 를 통해 k get pods -w 와 같이 무한으로(Control Loop) 리소스를 주시(Watch)합니다.

 

main.go 237

1. Indexer 에 추가적인 리소스를 추가해줍니다.

 

main.go 262

1. 위에서 생성한 Controller 객체를 실행합니다. 뒤에 있는 workers 는 Reconciliation 의 2번째 단계인 Analyze 와 3번째 단계인 Act 를 수행할때 처리할 병렬 갯수입니다.
2. go routine 으로만 실행되는 Controller 를 포그라운드로 영구적으로 실행합니다.

 

main.go 145

앞서 실행했던 Controller.Run() 의 구현 코드입니다.

1. informer.Run 을 고루틴으로 실행합니다. 뒤에서 살펴보겠지만, stopCh 이 close 될때까지 ListWatch 를 통해 무한으로(Control Loop) 쿠버네티스의 리소스를 주시(Watch) 합니다.
2. c.runWorker() 는 wait.Until 고루틴으로 실행됩니다. c.runWorker() 은 Analyze 와 Act 를 수행하는 함수로 뒤에서 다룹니다.

 

wait.Until 은 꽤나 중요한 함수이므로 한번 살펴보겠습니다.

backoff.go 211

1. wait.Until() 를 타고, 타고 들어가면 결국 BackoffUntil 이라는 함수가 나오게 됩니다. 문제가 생겼을 경우 바로 종료하는게 아니고, Backoff 을 진행해서 계속 문제를 해결하려고 노력하는 거죠. 
2. 그리고 문제가 없더라도 중간에 넘겨받은 f() 를 for{} 을 통해 계속해서 실행시킵니다.

어? 여기서 한가지 의문이 생길 수 있을 겁니다. "for{} 을 돌게되면 무한정으로 쉴틈없이 f() 가 실행될텐데 이거 맞아?"

 

main.go 52

앞에서 WorkQueue 를 생성했던거 기억나시나요? Informer 는 ListWatch 를 통해 가져오는 리소스를 WorkQueue 에 추가합니다.

그리고 go wait.Until(c.runWorker, time.Second, stopCh) 을 수행하는데 c.runWorker 함수 안을 보게되면 processNextItem 이 실행되고 processNextItem 안에는 c.queue.Get() 을 하게 됩니다.

 

즉, WorkQueue 에서 쿠버네티스 리소스를 빼옵니다.

 

그런데 c.queue.Get() 를 자세히 들여다보면, Lock() 이 걸려있는걸 확인할 수 있습니다. 

queue.go 278

정리하자면 wait.Util() 은 for{} 때문에 쉴틈없이 무한정으로 돌 수 있지만, Lock() 을 통해 고루틴을 블록해버리는 거죠! 그리고 defer() 를 통해 Unlock() 을 시켜줍니다.

 

수정!! 실질적으로 고루틴을 블록하는 건 for q.queue.Len() == 0 && !q.shuttingDown {} 내에 있는 q.cond.Wait() 입니다.
물론 Lock 을 해주지만 for 문이 없으면 결국 Unlock 이 되버리죠.

 

그럼 이제 Informer 가 어떻게 동작하는지 조금 더 자세히 살펴보죠!

controller.go 135

controller.go 는 kubernetes/client-go 에서 제공됩니다.

1. Reflector 객체를 생성합니다. 이 객체는 쿠버네티스 API 에서 리소스를 가져오는 역할을 수행합니다.
2. r.Run() 을 통해 Reflector 의 ListWatch 를 실행시킴으로써, 지속적으로 쿠버네티스 리소스를 주시(Watch) 할 수 있습니다. 이 부분은 Reconciliation 의 첫번째 스텝인 Observe 를 수행하게 됩니다.
3. processLoop 이 wait.Until 을 통해 실행되는데, 들어가보면 c.config.Queue.Pop() 이 for{} 을 통해 무한정으로 돌고 있습니다. 여기서 말하는 Queue 는 WorkQueue 는 아니고, ListWatch 를 통해 가져오는 리소스를 담는 Queue 입니다.

 

reflector.go

1. ListAndWatch() 를 실행함으로써 Observe 를 하고 있습니다.

추가적으로 r.typeDescription 에는 실제로 주시(Watch) 하고 있는 리소스의 타입을 담고 있습니다. 예를 들어 v1.ConfigMap, v1.Pod 처럼 말이죠.

 

그럼 지금까지 살펴본 것들은 한번 정리해보겠습니다.

 

Informer 는 ListWatch 를 통해 Control Loop 을 진행하면서 쿠버네티스 리소스를 가져오는 역할을 수행합니다. Add/Update/Delete 이벤트가 발생했을 때 WorkQueue 에 리소스 key 를 넣은 후, 추후 Reconciliation 의 2번째 단계인 Analyze 와 3번째 단계인 Act 를 수행할 수 있도록 밑바닥을 다집니다.

 

main.go 145

c.informer.Run 은 살펴봤으니. 이제는 c.runWorker 에 대해서 알아보죠.

1. c.runWorker 또한 wait.Until 고루틴을 통해 실행됩니다.

 

main.go 169

1. runWorker 안에는 processNextItem() 이 false 일때까지 for{} 을 통해 무한정으로 돌게 됩니다.

 

main.go 52

1. 앞서 informer 객체를 생성할 때 Add/Update/Delete 이벤트가 발생했을 때 queue.add(key) 를 통해 key 를 넣어줬는데, 이번엔 Get() 을 통해 key 를 가져옵니다. (Get() 함수 안에는 pop() 이 있음) 그리고 이 queue 가 비어있는 상태라면 false 를 리턴함으로써 c.processNextItem() 을 종료합니다.
2. c.syncToStdout(key) 는 Reconciliation 의 Analyze 와 Act 에 관한 비즈니스 로직을 구현하는 함수입니다. (syncToStdout 라는 이름 말고 다른 이름으로 지어도 전혀 상관 없음)

 

main.go 73

ConfigMap 의 Annotations 를 가져온 후에, "restart-deployment" Annotation 의 value 를 가져옵니다. 해당 value 는 재시작할 Deployment 의 이름을 가지게 됩니다.

 

그리고 위에서 가져온 Deployment 의 이름을 통해 Deployment 의 정보를 가져옵니다. Deployment 의 LabelSelector 를 통해서 맵핑된 Pod 또한 가져옵니다.

 

이후 가져온 Pod 를 전부 삭제해서 재시작되도록 합니다. 이렇게 함으로써 변경된 ConfigMap 의 데이터 값이 파드에 적용되도록 합니다.

 

이를 통해 Analyze 와 Act 도 구현하였고, 간단한 Controller 를 만들었습니다.

Operator 도 만들 수 있는데, Operator 같은 경우 operator-sdk 를 이용해서 만드는 것을 추천드립니다.

 

그럼 이제 실제로 Kubernetes 의 ReplicaSet 은 어떤 방식으로 Control Loop 돌면서 Reconciliation 을 수행하는지 살펴보겠습니다.

 

ReplicaSet 코드 까보기

---

 

kubernetes/cmd/kube-controller-manager/app/controllermanager.go

newReplicaSetControllerDescripto() 를 통해 ReplicaSet 에 관한 ControllerDescriptor 객체를 생성합니다.

 

kubernetes/cmd/kube-controller-manager/app/app.go

그리고 newReplicaSetControllerDescripto() 를 타고 들어가면 startReplicaSetController 함수를 가지고 있는 걸 확인할 수 있습니다.

 

kubernetes/cmd/kube-controller-manager/app/app.go

NewReplicaSetController 객체에 InformerFactory 를 이용해서 ReplicaSet 과 Pods 리소스의 Informer 를 추가해서 생성 한 후 Run() 을 실행하게 됩니다.

 

kubernetes/pkg/controller/replicaset/replica_set.go

여기서부터는 예제와 크게 다를 바가 없습니다. go wait.UntilWithContext 함수를 통해서 rcs.worker 를 실행합니다.

 

kubernetes/pkg/controller/replicaset/replica_set.go

rsc.queue 에서 key 를 가져온 후에 rsc.syncHandler 를 실행하게 되는데,

 

kubernetes/pkg/controller/replicaset/replica_set.go

여기에 우리가 아는 그 ReplicaSet 이 하는 행위가 작성되어있습니다.

 

확실히 만들었던 예제보다 훨씬 더 많이 추상화가 되어 있기 한데, 큰 틀에서는 비슷한걸 확인할 수 있었습니다.

 

쿠버네티스 Controller Manager 는 "불꽃 같은 눈빛"으로 쿠버네티스 리소스들을 주시(Watch) 하고 있습니다. 늘 이 "불꽃 같은 눈빛"을 코드로 어떻게 구현했는지 궁금했는데 이제는 답을 알것 같습니다.

 

고루틴으로 Informer 객체와 ListWatch 를 실행해서 리소스를 무한정으로(Control Loop) 바라보다가, Add/Update/Delete 이벤트가 발생하면 이를 WorkQueue 에 넣게 되고,  고루틴으로 wait.Util(로직) 을 수행함으로써 들어오는 이벤트에 대해 Reconcile 을 수행하는 것이였습니다.

 

이렇게 이번 글에서는 Controller 의 Low 한 부분까지 알아봤는데, 나중에 Controller Manager 의 컨트리뷰터도 한번 도전해봐야겠네요!

 

그럼 오늘은 여기까지!