CRD & Operator

CRD

• Custom Resource Definition의 약자로, 쿠버네티스에 새로운 리소스 타입을 추가할 때 사용된다.

• 다른 쿠버네티스 객체들과 동일하게 처리된다.

• CRD 정보는 etcd 데이터베이스에 저장된다.

• API의 표준 액션인 create, get, list, watch, delete 등을 모두 지원한다.

사용법

• 쿠버네티스 리소스의 구조를 기술하는 스키마를 CRD 객체로 생성한다.

• 다음은 todo 항목을 저장하는 간단한 쿠버네티스 객체를 정의하는 CRD 예시이다.

apiVersion: apiextensions.k8s.io/v1  # minimum 1.16
kind: CustomResourceDefinition
metadata:
  name: todos.ch20.kiamol.net
  labels:
    kiamol: ch20
spec:
  group: ch20.kiamol.net
  scope: Namespaced
  names:
    plural: todos
    singular: todo
    kind: ToDo
    shortNames:
    - td
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                item:
                  type: string
                dueDate:
                  type: string
                  format: date 

• 다음은 위 CRD 스키마에 따라 정의된 CRD 리소스의 객체 예시이다. apiVersion과 리소스 유형이 CRD와 일치해야 한다.

apiVersion: "ch20.kiamol.net/v1"
kind: ToDo
metadata:
  name: ch20
  labels:
    kiamol: ch20
spec:
  item: "Finish KIAMOL Ch20"
  dueDate: "2020-07-26"

• kubectl get todos 명령으로 현재 생성된 ToDo 리소스 객체들 목록을 확인할 수 있고, kubectl delete todo ch20 명령으로 커스텀 객체를 제거할 수 있다.

• 이러한 형태는 예시일 뿐이고 실제로 CRD를 사용할 때에는 리소스나 클러스터 기능을 확장하는 용도로 사용해야 한다.

• kubectl delete crd <crd name> 명령으로 CRD 자체를 삭제하면 모든 객체가 사라지므로 CRD 리소스에 대한 RBAC 권한을 엄격히 관리해야 한다.

• 사용자 정의 컨트롤러와 함께 사용하여 CRD 객체를 관리하도록 할 수 있다. 하지만 관리자가 특정 CRD 객체를 직접 관리하거나 삭제해도 문제가 없도록 컨트롤러 로직을 구성해야 한다. 예를 들어 CRD 객체의 네임스페이스, 비밀값 등이 사라졌다면 다시 생성해주어야 한다.

오퍼레이터

• CRD 및 컨트롤러를 사용해 애플리케이션에 완전한 생애 주기 관리를 제공한다.

• 쿠버네티스 기본 리소스와 확장성을 활용해 애플리케이션을 생성하기 쉽고 유지보수하기 쉽도록 지원한다.

• 데이터베이스 업그레이드 시 읽기 전용으로 변경하고 백업한 후 업그레이드해야 하는 경우가 존재한다. 이 때 내장된 쿠버네티스 리소스나 헬름을 이용해서 구현하기는 어렵다. 오퍼레이터를 이용하여 이러한 작업들을 구현해 추상화시킬 수 있다.

• 오퍼레이터를 배치하면 서드파티 컴포넌트를 하나의 서비스처럼 사용할 수 있도록 관리해준다.

• 이 때 파드는 디폴로이먼트나 스테이트풀셋 대신 오퍼레이터가 컨트롤러 역할을 하여 관리한다.

• 다음은 MySQL 오퍼레이터를 통해 복제 데이터베이스를 동작시키기 위한 CRD이다.

  • todo-db-mysql 이라는 스테이트풀셋에 복제 데이터베이스 파드들이 동작하게 된다.

  • 데이터베이스 파드에는 MySQL 컨테이너와 함께 측정값 지표 수집을 위한 prometheus exporter 컨테이너 등 사이드카 컨테이너가 함께 띄워지므로 직접 세부 구성을 조정하지 않아도 편리하게 사용할 수 있다.

apiVersion: v1
kind: Secret
metadata:
  name: todo-db-secret
  labels:
    kiamol: ch20
type: Opaque
stringData:
  ROOT_PASSWORD: "kiamol-2*2*"
---
apiVersion: mysql.presslabs.org/v1alpha1
kind: MysqlCluster
metadata:
  name: todo-db
spec:
  mysqlVersion: "5.7.24"
  replicas: 2
  secretName: todo-db-secret  
  podSpec:    
    resources:
      limits:
        memory: 200Mi
        cpu: 200m

장점

• 애플리케이션 매니페스트에서 애플리케이션과 관련된 내용에만 집중할 수 있다.

• 가용성과 배치 편의성을 높여준다.

• 핵심 컴포넌트의 업그레이드를 대신해주는 효과가 있다.

• 데이터베이스 백업 기능 등 다양한 부가 기능을 제공할 수 있다.

직접 작성하기

• 애플리케이션에 복잡한 운영 작업이 필요하거나 여러 프로젝트에서 서비스 형태로 쓰이는 공통 컴포넌트를 관리하기 위해 오퍼레이터를 직접 작성할 수 있다.

• Go 언어로 오퍼레이터 구현 시, Kubebuilder 또는 OperatorSDK를 사용해 코드 템플릿을 만들 수 있다.

오퍼레이터 사용 예시

• CRD에 애플리케이션의 설정 값을 지정하면 오퍼레이터가 해당 값들을 이용해 실제 애플리케이션 인스턴스를 구동하도록 한다.

• 애플리케이션을 구동했을 때 발생한 로그를 처리하기 위한 CRD와 오퍼레이터를 사용할 수도 있다.

• 아래는 애플리케이션 CRD와 애플리케이션 로그 처리 CRD를 관리할 오퍼레이터를 디플로이먼트 형태로 구동하는 예시이다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-ping-operator
  labels:
    kiamol: ch20
spec:
  selector:
    matchLabels:
      app: web-ping-operator
  template:
    metadata:
      labels:
        app: web-ping-operator
    spec:
      serviceAccountName: web-ping-operator
      automountServiceAccountToken: true
      initContainers:
        - name: installer
          image: kiamol/ch20-wpo-installer
      containers:
        - name: pinger-controller
          image: kiamol/ch20-wpo-pinger-controller
        - name: archive-controller
          image: kiamol/ch20-wpo-archive-controller

• 애플리케이션 커스텀 리소스를 아래와 같이 작성하면 오퍼레이터는 이를 감지하여 새로운 애플리케이션 인스턴스를 구동하게 된다.

apiVersion: "ch20.kiamol.net/v1"
kind: WebPinger
metadata:
  name: blog-sixeyed-com
  labels:
    kiamol: ch20
spec:
  target: blog.sixeyed.com
  method: HEAD
  interval: "7s"