Kubenetes Operator Study - Concept for newbie (1) Controller and Operator

안녕하세요 휘영청입니다.

 

이번에 쿠버네티스 오퍼레이터 Study를 하게 되었습니다 :)

 

화려한 블로그는 할 수 없는 뉴비라 어떻게 하면

모두가 이해할 수 있을만큼

개념을 쉽게 정리할 수 있을까 하는 마음으로 블로그를 적어보게 되었습니다!

---

 

[쉽게 잡고가는 개념]

 

1) 오퍼레이터(Operator)는 사용자 정의 리소스를 사용하여 애플리케이션 및 해당 컴포넌트를  2)관리하는 쿠버네티스의 소프트웨어 3)익스텐션(확장) 이다. 4) 오퍼레이터는 쿠버네티스 내부에서 제어 루프를 따른다.

참조 : https://kubernetes.io/ko/docs/concepts/extend-kubernetes/operator/

 

 1) 오퍼레이터가 뭔데?

 

오퍼레이터는 쿠버네티스 추상화를 통해 관리 대상 소프트웨어의

전체 라이프사이클을 자동화, 애플리케이션을 패키징-배포-관리하는 방법론이라고 합니다.

쿠버네티스부터가 도커 호스트(컨테이너)를 관리하는 오케스트레이션인데

이제는 더 잘 사용하고 싶게 된 니즈를 만족하기 위해서 오퍼레이터가 등장하게 된 것입니다.

쿠버네티스는 자동화를 위해 설계된 것이니만큼 이것을 더 섬세하게 관리할 수 없을까?

 

 

관리할 수 있는 시스템을 더 잘 관리하고 싶다.

즉, 오퍼레이터는 쿠버네티스의 프로그램들이 잘 돌아가게끔 실행하고 관리하는 것이다.

 

마치 호텔을 더 싸게 예매하고 싶어서 호텔 할인 사이트가 생겼는데 그 할인사이트를 비교해주는 사이트가 늘어나고

그걸 또 비교해주는 사이트가 늘어나고.. 관리는 쉴 새 없이 해야하나봐요 >ㅁ<

할인 받기 위한 사이트를 또 정리해준 사이트인데 그걸 또 정리한 사이트같은 느낌

 

2) 그럼 어떻게 관리를 하는거지?

 

그럼 기존에 있는 것과는 어떻게 관리를 다르게 하는지 한번 비교해볼게요.

 

[기존의 쿠버네티스 동작 흐름]

 

yaml 파일을 이용해서 kubectl 명령어를 작동시키면

마스터 노트 내부에 있는 컨트롤러가 특정 리소스에게 작업을 합니다.

컨트롤러가 하는 것

컨트롤러는 특정 리소스를 지속적으로 바라보며 리소스의 생명주기에 따라 미리 정해진 작업을 수행하는 주체입니다. 예를 들면 파드나 노드(특정 리소스)가 죽었을 때(생명주기) 컨트롤러가 즉각적으로 대응을 한다던지, 소프트웨어의 버전을 업그레이드를 하거나, 파드(특정 리소스)를 부하 분산을 해서 파드를 죽지 않게 하거나(생명주기), 파드(특정 리소스)가 더 필요해서 일시적인 작업을 해야할 경우 필요한 순간에만 만들고 삭제를 할 수 있다거나 말이죠!

 

보통 쿠버네티스에서 컨트롤 플레인의 컨트롤러는 마스터 노드내부에 있고

클러스터의 원하는 상태를 제어할 수 있게 루프를 만들곤하죠.

 

그런데 이걸 모니터링도 하고 편하게 정의할 수 없을까?

 

 

컨트롤러를 사용자가 따로 뚝 떼어내서 관리하면 좋겠다

3) Extension!

[Operator 사용시  쿠버네티스 동작 흐름]

 

제가 이해한 오퍼레이터는 이렇습니다.

마스터노드가 아니라 밖에서 확장(extension)으로 쿠버네티스 API 기능을, 사용자를 대신해서 

어플리케이션을 설정하고 생성하고 관리까지 할 수 있는 어플리케이션마다 컨트롤 할 수 있는거죠.

 

4) 제어 루프

컨트롤러가 특정 리소스를 지속적으로 바라보며

리소스의 생명주기에 따라 미리 정해진 작업을 수행하는 주체라고 했는데

 

이걸 다르게 말하면

 

미리 정해진 작업을 수행한다

= 원하는 상태와 맞지 않는다면 해결하기 위해서 작업을 수행한다

= 고정시켜놓은 (제어) 루프를  만든다

 

원하는 상태가 뭔지 확인하고, 현재 상태가 어떤지 object를 확인하고 원하는 상태로 바꾸어 주는걸

반복해서 지속적으로 유지하게 하는 것 입니다 :)

 

---

[ 어떻게 작동하는걸까? ] 

그럼 어떻게 동작을 할 수있을까요?

 

자동화를 하기 위해서는 그게 맞는 컨트롤러를 만들어야죠 :)

 

쿠버네티스 API 기능을 확장해서 사용한다고 했는데 무엇을 어떻게?!

3가지를 알면 됩니다.

 

Custom Resource Definitions (CRD)

Custom Resources(CR)

Custom Controller(CC)

- 그냥컨트롤러라고하기도..

 

를 사용하여 애플리케이션과 그 내부 구성 요소를 관리하는 사용자가 정의합니다.

https://kubernetes.io/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/

 

쿠버네티스 Control Plane 을 확장하여 쿠버네티스 관리자를 대신해주는 관리자(?!)

 

Custom Resource Definitions (CRD)
Custom Resources(CR)
Custom Controller(CC)

이 세가지는 각각 이렇게 정의하면 편할 것 같아요.

• Custom Resource Definition (CRD) :  원하는 상태가 뭔지 확인하는 것이 필요하다고 했죠? 그럼 그것을 정의해야하는 것이 필요합니다. CR을 사용하기 위해서 사용하는 방법이죠. 어떻게 구성되어있는지 정의하는 것일뿐. 실제로 생성하는 것은 아닙니닷!
  
• Custom Resource (CR) : 원하는 목적의 오브젝트를 직접 구현해 사용할 수 있고 여러 종류의 리소스를 추상화해 관리할 수도 있는 인터페이스입니다. Custom Resource Definition (CRD) 는 작성할 때 다양한 언어가 사용가능합니다. 코드 작성이 필요 없이 YAML 로 된 스키마로 작성할 수 있죠. 그리고 확장 기능이니까 별도의 관리는 노놉!
  
• Controller : 원하는 상태랑 일치하는지 현재의 상태를 구성해주는 컨트롤러입니다.

 

---

[실습하기]

가시다님 DOIK 스터디 2주차 - 오퍼레이터 & MySQL 오퍼레이터에 있는 내용을 참고하였습니다.

 

CRD 생성 및 확인

1) 먼저 CRD의 샘플 YAML 파일을 확인합니다.

(🚴|DOIK-Lab:default) root@k8s-m:~# cat ~/DOIK/2/resourcedefinition.yaml
───────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
       │ File: /root/DOIK/2/resourcedefinition.yaml
───────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ apiVersion: apiextensions.k8s.io/v1
   2   │ kind: CustomResourceDefinition # 사용자 정의 리소스(CRD) 생성
   3   │ metadata:
   4   │   # name must match the spec fields below, and be in the form: <plural>.<group>
   5   │   name: crontabs.stable.example.com # <NAMES>.<GROUP> 으로 정의
   6   │ spec:
   7   │   # group name to use for REST API: /apis/<group>/<version>
   8   │   group: stable.example.com    # apiVersion 그룹 이름(<GROUP>) 을 지정
   9   │   # list of versions supported by this CustomResourceDefinition
  10   │   versions:               # CRD 버전 정의
  11   │     - name: v1
  12   │       # Each version can be enabled/disabled by Served flag.
  13   │       served: true
  14   │       # One and only one version must be marked as the storage version.
  15   │       storage: true
  16   │       schema:
  17   │         openAPIV3Schema:
  18   │           type: object
  19   │           properties:
  20   │             spec:
  21   │               type: object
  22   │               properties:
  23   │                 cronSpec:
  24   │                   type: string
  25   │                 image:
  26   │                   type: string
  27   │                 replicas:
  28   │                   type: integer
  29   │   # either Namespaced or Cluster
  30   │   scope: Namespaced     # Cluster 레벨 리소스인지 vs Namespace 레벨 리소스인지 지정하기
  31   │   names:
  32   │     # plural name to be used in the URL: /apis/<group>/<version>/<plural>
  33   │     plural: crontabs					# 복수 이름(plural)
  34   │     # singular name to be used as an alias on the CLI and for display
  35   │     singular: crontab					# 단수 이름(singular)
  36   │     # kind is normally the CamelCased singular type. Your resource manifests use this.
  37   │     kind: CronTab						# kind 이름
  38   │     # shortNames allow shorter string to match your resource on the CLI
  39   │     shortNames:						# 축약 이름
  40   │     - ct

 

2) CRD 를 생성합니다

(🚴|DOIK-Lab:default) root@k8s-m:~# kubectl apply -f ~/DOIK/2/resourcedefinition.yaml
customresourcedefinition.apiextensions.k8s.io/crontabs.stable.example.com created

 

3) CRD 생성을 확인해봐야겠죠? 

(🚴|DOIK-Lab:default) root@k8s-m:~# k get crd | grep crontabs
crontabs.stable.example.com           2022-06-10T12:45:55Z

 

CR 생성 및 리소스 확인

(🚴|DOIK-Lab:default) root@k8s-m:~# cat ~/DOIK/2/my-crontab.yaml
───────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
       │ File: /root/DOIK/2/my-crontab.yaml
───────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ apiVersion: "stable.example.com/v1"
   2   │ kind: CronTab
   3   │ metadata:
   4   │   name: my-new-cron-object
   5   │ spec:
   6   │   cronSpec: "* * * * */5"
   7   │   image: my-awesome-cron-image
───────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
(🚴|DOIK-Lab:default) root@k8s-m:~# kubectl apply -f ~/DOIK/2/my-crontab.yaml
crontab.stable.example.com/my-new-cron-object created
(🚴|DOIK-Lab:default) root@k8s-m:~# kubectl get crontab
NAME                 AGE

리소스 상세 정보확인 - 축약어로 ct

(🚴|DOIK-Lab:default) root@k8s-m:~# kubectl get ct -o yaml
apiVersion: v1
items:
- apiVersion: stable.example.com/v1
  kind: CronTab
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"stable.example.com/v1","kind":"CronTab","metadata":{"annotations":{},"name":"my-new-cron-object","namespace":"default"},"spec":{"cronSpec":"* * * * */5","image":"my-awesome-cron-image"}}
    creationTimestamp: "2022-06-11T09:18:29Z"
    generation: 1
    name: my-new-cron-object
    namespace: default
    resourceVersion: "318340"
    uid: d7924a4d-376e-46ff-b846-522fe296c29a
  spec:
    cronSpec: '* * * * */5'
    image: my-awesome-cron-image
kind: List
metadata:

 

** 현재는 리소스만 생성한 상태도 실제로 어떻게 동작을 수행해야한다면 custom controller를 사용한다.

 

Operator는 이 세 가지가 있어야지 특정 어플리케이션의 생성과 삭제를 같이 할 수있습니다.

현재는 컨트롤러가 없어서 사용할 수 없지만, 다음 블로그에는 컨트롤러까지 함께 사용해서 서비스를 만들어보는 테스트를 하려고합니다 :)

 

다음 블로그를 기대해주세요 (찡긋) >_0

 

 

#쿠버네티스 #쿠버네티스스터디 #kubernetesstudy #kubernetesoperator