쿠버네티스 Operator Pattern

Operator는 Kubernetes 클러스터 내 소프트웨어에서 실행하는 공통되고 반복되는 활동을 Kubernetes의 컨셉과 API를 사용해서 구현하고 자동화하였고 이를 Kuberentes Native Application이라고 한다.

 

Operator를 사용하면 Pods, Deployments, Services, ConfigMap 같은 primitives 타입을 쓰지 않고, 필요한 옵션만 지정하는 단일 객체로 애플리케이션을 쓸 수 있다.

 

정리하자면 쿠버네티스 Operator는 Kubernetes의 확장성과 자동화 기능을 극대화해주는 중요한 구성 요소이다.

운영자의 반복적인 수작업을 자동화하고 복잡한 애플리케이션을 효율적으로 관리할 수 있게 도와준다. Operator는 일반적으로 애플리케이션 라이프사이클 관리(설치, 업그레이드, 모니터링, 장애 조치 등)를 포함하여 인프라 및 애플리케이션의 상태를 지속적으로 유지보수하는 역할을 수행한다. 이전에 helm을 통해 설치한 Prometheus&Grafana 등은 모두 이 Operator 패턴으로 이루어져있다.

 

1. Kubernetes Operator의 개요와 필요성

Operator는 쿠버네티스의 '컨트롤러' 개념을 확장하여 애플리케이션이나 인프라를 정의한 후, 쿠버네티스 리소스를 활용해 이를 관리하도록 돕는 구조이다. 단순히 Pod이나 Service를 배포하는 수준을 넘어, Stateful 애플리케이션이나 데이터베이스 같은 복잡한 시스템의 라이프사이클 전체를 관리하는 데 유용하다.

쿠버네티스는 기본적으로 네이티브 리소스(Pod, Deployment 등)에 대한 컨트롤러를 제공하지만, 사용자가 정의한 애플리케이션에 맞는 맞춤형 관리 로직을 지원하지는 않는다. 이 지점에서 Operator가 필요하며, 이를 통해 쿠버네티스의 선언형 관리 방식을 보다 유연하게 적용할 수 있다.

2. 주요 개념: Custom Resource(CR)와 Custom Resource Definition(CRD)

Operator의 핵심 구성 요소는 Custom Resource (CR)와 Custom Resource Definition (CRD)이다.

CRD는 단지 정의하는 것이고 CR을 생성하면 CRD를 기반으로 실제 리소스가 생성되는 것이라고 이해하면 될 것 같다.

CR, CRD 및 컨트롤러까지 직접 만들어 사용할 환경은 아니였지만 카프카, 프로메테우스 등 Operator 패턴을 활용하고 있었고 이는 CRD, CR로 리소스를 관리하고 있었기에 무슨 개념인지는 알아둬야한다 생각하였다.

 

간단한 예제만 살펴보고 필요 시 추가적으로 찾아보도록 하자.  

이건 GPT가 만들어준 예제코드이다. 잘 돌아갈 지는 모르겠다. 대충 CR, CRD가 무엇인지 감만 잡기 위해 참고용도로 활용하였다.

Custom Resource Definition (CRD)

CRD는 쿠버네티스 클러스터에 새로운 리소스 유형을 정의하는 매커니즘이다. 이를 통해 기본 쿠버네티스 리소스 외에도 사용자 정의 리소스를 추가할 수 있으며, 쿠버네티스 API를 통해 이 리소스의 생성, 읽기, 업데이트, 삭제(CRUD)가 가능하다. 예를 들어 MySQLCluster, RedisCluster와 같은 CRD를 생성하면, 해당 애플리케이션에 필요한 독립적인 리소스가 생기고 쿠버네티스 API와 연동하여 이를 관리할 수 있다.

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: mysqlclusters.example.com
spec:
  group: example.com
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                replicas:
                  type: integer
                  description: "Number of MySQL instances"
                version:
                  type: string
                  description: "MySQL version"
  scope: Namespaced
  names:
    plural: mysqlclusters
    singular: mysqlcluster
    kind: MySQLCluster
    shortNames:
      - myc

Custom Resource (CR)

CR은 CRD로 정의된 리소스를 실제로 사용하는 구체적인 인스턴스이다. 예를 들어 MySQLCluster라는 CRD가 정의되었을 때, 특정 설정값을 가진 MySQLCluster 인스턴스(CR)를 생성하여 데이터베이스 클러스터를 배포할 수 있다. 이 CR은 선언적 방식으로 정의되며, Operator는 CR을 기반으로 필요한 리소스를 생성하거나 상태를 모니터링하며 목표 상태를 유지한다.

apiVersion: example.com/v1
kind: MySQLCluster
metadata:
  name: my-mysql-cluster
spec:
  replicas: 3
  version: "5.7"

 

그런데 여기서 궁금한 건 실제로 Mysql 인스턴스를 생성하려면 어떻게 해야할 지 의문점이 들었다. 쿠버네티스는 etcd에 저장된 값을 컨트롤러가 계속 확인하고 이 값을 맞추기 위해 동작한다. 이와 마찬가지로 찾아보니 커스텀 컨트롤러 혹은 Operator가 이 CRD를 감시하고 사용자가 CR을 생성하면 실제 서비스 등을 생성하는 역할을 한다고 한다.

쿠버네티스 아키텍쳐와 동일하다. Mysql CR이 생성되면 컨트롤러가 이를 감지 -> CR의 스펙을 확인한 후 지정된 (변수)값으로 서비스를 생성한다. -> CR이 업데이트되거나 삭제되면 컨트롤러가 이를 감지하여 리소스를 업데이트하거나 삭제한다. 

 

직접 소스를 구현하지는 않았지만 대충 이런 흐름을 가질거라고 예상된다.

Mysql CR 생성 감지 -> CR 정보 가져오기 -> Mysql Deployment & Service 생성, 이런 로직을 가진 서비스를 쿠버네티스 클러스터에 배포하면 되지 않을까 싶다. 

 

3. Operator의 주요 기능과 동작 원리

쿠버네티스의 컨트롤러(Controller)는 etcd를 감시하여 선언된 api에 맞게 원하는 상태로 만들어주려고 노력하는 컴포넌트이다.

대표적으로 pod을 생성하여 etcd에 넣어놓으면 그 변경을 컨트롤러가 감지하여 컨테이너를 띄워주게 된다.

 

커스텀 컨트롤러(Custom Controller)는 일반적인 pod, deployment, service가 아닌 custom resource(cr)을 처리하는 컴포넌트이다. CR과 CRD를 사용하여 만든 커스텀 리소스는 etcd에 올라가는 구조화된 데이터일 뿐이지 커스텀리소스를 이용해서 원하는 동작을 하기위해서는 커스텀 컨트롤러가 필요하다.

 

Operator는 이러한 커스텀 컨트롤러 역할을 포함하여 운영에 필요한 모든 것을 포함한다.

Operator가 수행하는 주요 기능은 다음과 같습니다:

• 설치 및 배포: 애플리케이션을 설치하고 쿠버네티스 클러스터에 배포한다. 예를 들어, MySQL Operator는 MySQL 클러스터의 인스턴스를 생성한다.
• 업그레이드 및 롤백: 애플리케이션 버전 업그레이드 및 롤백 기능을 제공한다. 새로운 버전이 배포될 때 데이터 백업, 마이그레이션 등 필요한 작업을 수행할 수 있다.
• 모니터링 및 복구: 애플리케이션의 상태를 모니터링하고 장애가 발생할 경우 자동으로 복구 작업을 수행한다. 이때 사용자 정의된 매개변수에 따라 여러 시나리오에 맞춘 복구 전략을 실행할 수 있다.
• 백업 및 복원: 데이터 백업과 복원을 관리하는 기능도 포함될 수 있다. 

4. Operator 프레임워크와 도구

쿠버네티스 Operator 개발을 돕는 도구와 프레임워크가 많이 존재한다. 대표적인 Operator 개발 프레임워크는 다음과 같다.

• Operator SDK: Red Hat이 제공하는 Operator 개발 도구로, Go, Ansible, Helm을 이용해 Operator를 개발할 수 있다.
• Kubebuilder: 쿠버네티스 API와 CRD를 기반으로 컨트롤러를 쉽게 구축할 수 있게 돕는 Go 기반의 프레임워크

이 외에도 Helm Operator와 같은 도구를 이용해 기존 Helm Chart를 기반으로 Operator를 개발하는 방법도 있다고 하는데 도큐먼트를 살펴보니 다양한 언어와 런타임을 지원하고 있다.

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

오퍼레이터(operator) 패턴

 

5. Operator 구현

Go에서 Operator SDK를 활용하여 구현한 예제

https://frozenpond.tistory.com/146

[kubernetes] operator-sdk를 사용하여 쿠버네티스 오퍼레이터 구축하기 (operator sdk 예제)

 

JAVA Operator SDK

https://javaoperatorsdk.io/docs/features/

Features

 

 

결론

쿠버네티스 Operator는 사용자 정의 리소스를 통해 복잡한 애플리케이션의 자동화와 라이프사이클 관리를 가능하게 하는 강력한 도구라 생각한다. CRD를 통해 쿠버네티스 API를 확장하고, CR을 활용해 추가적인 애플리케이션의 목표 상태를 선언적으로 관리할 수 있다. 이를 통해 쿠버네티스 환경에서 다양한 오브젝트의 객체들이 효율적으로 운영될 수 있다. 

하지만 Operator의 개발과 유지보수에는 기술력과 리소스가 요구된다고 생각한다. 복잡도가 높은 만큼 설계와 구현이 까다로울 수 있을 거 같다. 제공된 Operator를 사용만 했지 실제 CR, CRD를 만들어 직접 컨트롤러를 운영할 환경을 접해보지 못했다.  개념을 탑재하고 있으면 언젠간 도움이 될 날이 있을 거라고 생각한다.