들어가며
쿠버네티스를 사용하다 보면 CRD(Custom Resource Definition), 오퍼레이터(Operator) 같은 용어를 자주 접하게 됩니다.
👀 이 글에서는 이 개념들이 무엇이고, 어떤 역할을 하는지 정리해보려고 합니다.
먼저, 쿠버네티스는 기본적으로 유연성과 확장성을 위해 핵심 기능만 최소한으로 제공하고, 나머지는 API를 통해 얼마든지 확장할 수 있도록 설계되었습니다. 그리고 이러한 확장성을 구현하는 대표적인 기술이 Kubernetes Operator입니다.
Operator란?
쿠버네티스는 기본적으로 매우 강력한 자동화 기능을 제공합니다. 워크로드의 배포, 확장, 복구 같은 운영 작업뿐 아니라 쿠버네티스 자체가 동작하는 방식도 자동화할 수 있습니다.
Operator 패턴은 이러한 자동화 능력을 애플리케이션 수준까지 확장하기 위한 구조로, 쿠버네티스의 코드를 수정하지 않고도 클러스터의 기능을 자연스럽게 확장할 수 있게 해줍니다.
Operator는 쉽게 말해, 특정 Custom Resource를 감시하고, Kubernetes API를 사용해 애플리케이션 운영에 필요한 복잡한 작업을 자동으로 수행하는 컨트롤러 프로그램입니다.
🔎 여기서 개념 정리
1) Kubernetes API
쿠버네티스에서 이루어지는 모든 작업은 API 서버를 통해 처리됩니다. kubectl 명령, 기본 컨트롤러 조정(Reconcile), 그리고 Operator가 수행하는 자동화 로직까지 리소스 상태 조회, 스케일링, 재시작과 같은 모든 동작은 Kubernetes API 호출로 실행됩니다.
즉, Kubernetes API는 클러스터의 모든 상태를 읽고 수정하는 표준 인터페이스이며, Operator는 이 API를 사용해 "현재 상태"를 확인하고 "원하는 상태"와 다르면 필요한 조치를 자동으로 수행합니다.
2) CRD (Custom Resource Definition)
쿠버네티스는 기본적으로 Pod, Deployment, Service 같은 기본 리소스를 제공합니다. 하지만 이러한 기본 리소스만으로는 복잡한 운영 요구사항을 모두 만족하기 어렵습니다.
그래서 쿠버네티스는 사용자가 새로운 리소스 타입을 직접 정의할 수 있는 기능, CRD(Custom Resource Definition)를 제공합니다.
CRD를 클러스터에 등록하면 쿠버네티스는 해당 리소스를 기본 리소스처럼 인식하며, kubectl get, apply, delete 등 명령어로 관리할 수 있게 됩니다.
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: postgresclusters.postgres-operator.crunchydata.com
spec:
group: postgres-operator.crunchydata.com
names:
kind: PostgresCluster
plural: postgresclusters
scope: Namespaced
versions:
- name: v1
served: true
storage: true
schema:
openAPIV3Schema:
...3) CR (Custom Resource)
CRD가 "리소스의 설계도"라면, CR은 그 설계도를 바탕으로 실제로 생성된 리소스 객체입니다.
-
CRD: PostgresCluster
→ "PostgresCluster라는 리소스 타입이 존재한다"는 선언 -
CR: my-db
→ "my-db라는 이름의 Postgres 클러스터를 생성하라"는 실제 리소스 객체
apiVersion: postgres-operator.crunchydata.com/v1
kind: PostgresCluster
metadata:
name: my-db
spec:
instances:
- replicas: 3왜 Operator가 필요할까?
쿠버네티스는 "단순함 + 유연함 + 자동화"를 목표로 설계된 컨테이너 오케스트레이터입니다. 하지만 기본 리소스(Pod, Deployment, Service 등)만으로는 복잡한 애플리케이션의 운영 로직을 처리하기 어렵습니다.
예를 들어 PostgreSQL, Elasticsearch, Kafka 같은 상태 기반(Stateful) 애플리케이션은 초기 설치 및 설정, 데이터 백업, 버전 업데이트, 장애 복구 ... 등과 같은 다양한 복잡한 운영 작업이 필요합니다.
이러한 반복적이고 복잡한 운영 로직을 자동화하는 것이 Operator입니다. 즉, 쿠버네티스가 제공하는 기본 기능을 애플리케이션 도메인 수준까지 확장해 줍니다.
어떻게 사용할 수 있을까?
Operator는 Custom Resource Definition(CRD) 과 함께 동작합니다. 우선 CRD를 통해 새로운 리소스 타입을 쿠버네티스에 등록하고, Operator는 이 리소스의 상태를 감시하며 생명주기를 자동으로 관리합니다.
1) 기존 Operator 설치
Postgres, Elasticsearch, Prometheus 등 많은 오픈소스 프로젝트가 자체 Operator를 제공하며, Helm이나 OperatorHub를 통해 쉽게 설치해 사용할 수 있습니다.
2) 직접 Operator 구현
Kubebuilder나 Operator SDK를 사용해 CRD 정의, 컨트롤러(Reconcile 로직) 구현, 클러스터 배포의 순서로 직접 Operator를 개발할 수도 있습니다.
참고
🔗 https://kubernetes.io/ko/docs/concepts/extend-kubernetes/operator/
🔗 https://www.cncf.io/blog/2022/06/15/kubernetes-operators-what-are-they-some-examples/
🔗 https://kubernetes.io/ko/docs/concepts/overview/kubernetes-api/
