K8S 오퍼레이터 패턴

 

오퍼레이터 패턴이 필요한 이유

쿠버네티스는 배포/스케일링/헬스체크 같은 범용 자동화는 잘 지원하지만, 특정 애플리케이션 도메인에 특화된 로직은 제공하지 않는다.

예를 들어, OpenSearch 인덱스를 특정 규칙에 따라 생성하고 RBAC까지 세팅해야 한다면? 단순한 Deployment/ConfigMap 수준의 조합으로는 부족하다.

즉, 이러한 부족한 도메인 요구사항을 충족할 때 오퍼레이터 패턴을 도입할 수 있다.

• 오퍼레이터는 사용자가 정의한 리소스(Custom Resource, CR) 와 이를 지속적으로 관리하는 컨트롤러(Controller) 를 결합하여, 애플리케이션을 쿠버네티스 네이티브 방식으로 관리할 수 있도록 해준다.

Desired State vs. Actual State

쿠버네티스의 핵심 철학은 "원하는 상태(desired state)"와 "실제 상태(actual state)"의 차이를 지속적으로 조정(reconcile)한다는 것이다.
예를 들어 Deployment의 spec.replicas = 3 으로 설정하면, 컨트롤러는 파드 수가 3개가 되도록 계속 상태를 맞춘다.

오퍼레이터는 이 원리를 확장하여, 커스텀 리소스를 관리하기 위한 specialized 된 컨트롤러를 구현하는 것을 말한다.
즉, 커스텀 리소스의 .spec 값에 기재된 원하는 상태와, 실제 상태를 .status 를 비교하며, 두 상태가 일치할 때까지 컨트롤 루프를 돌며 자동 조정하는 것이다.

좀 더 자세하게는 컨트롤러의 동작방식은 아래처럼 이해해볼 수 있다.

1. 사용자의 원하는 상태에 대한 요청은 Custom Resource의 .spec에 기록된다.
2. 컨트롤러는 .spec 내용을 실제 객체(ex. RedisService 또는 OpenSearch 와 같은 도메인 리소스)에 반영하려고 시도한다.
3. 실제 객체에 반영을 성공하면 .status 를 갱신한다.
4. .spec == .status 상태가 되면 컨트롤러는 더 이상 동작하지 않는다.

오퍼레이터의 핵심 이점

1. 상태 지향 자동화 (State-oriented automation)
   • 쿠버네티스의 기본 철학인 desired state vs. actual state 개념을 확장한다.
   • 오퍼레이터는 사용자가 정의한 .spec을 기준으로 .status를 지속적으로 맞추며, 복잡한 운영 절차조차 선언적으로 자동화할 수 있다.
2. 애플리케이션 도메인 전용 로직 (Application-specific operational logic)
   • 쿠버네티스 기본 리소스(pod, service, deployment 등)만으로는 처리하기 어려운 도메인 특화 요구사항을 커버할 수 있다.
   • OpenSearch, Kafka, Redis 같은 특정 워크로드에 맞는 전용 컨트롤러를 구현하여, 애플리케이션 레벨의 운영 지식을 자동화한다.
3. 쿠버네티스 네이티브 통합 (Kubernetes-native integration)
   • CRD(Custom Resource Definition)를 통해 애플리케이션을 쿠버네티스의 리소스처럼 다룰 수 있다.
   • 따라서 기존 쿠버네티스 API 및 kubectl 명령어 체계 안에서 동일하게 관리할 수 있어, 학습 곡선이 낮고 운영 일관성이 높아진다.

오퍼레이터 개발

오퍼레이터는 컨트롤러와 인포머(Informer)를 통해 동작한다.

• Informer: API 서버와 watch를 통해 리소스 변화를 감지하고 캐시에 저장.
• Controller: 캐시에서 객체를 가져와 reconcile 수행 후, 상태를 API 서버에 업데이트.

이를 통해 클러스터 내 리소스(파드, 서비스, CR 등)의 변경 사항을 실시간으로 감지 → 조정 → 반영하는 자동화 루프 완성

컨트롤러 내부 흐름 정리

LY 블로그를 통해서 컨트롤러의 동작 방식을 좀 더 자세히 이해할 수 있었다.

1. API 서버 ↔ etcd: etcd의 Watcher가 변화 이벤트를 감지하고, API 서버로 전달
2. Reflector → DeltaFIFO → 캐시: Reflector가 이벤트를 받아 DeltaFIFO 큐에 넣고 캐시를 업데이트
3. 이벤트 핸들러 → WorkQueue: Reflector가 이벤트 알림을 보내면, 핸들러가 해당 리소스의 namespacedName을 WorkQueue에 푸시
4. Reconcile 함수 처리: WorkQueue에서 namespacedName을 꺼내, 캐시에서 실제 오브젝트를 조회하고, .spec과 .status를 비교해 필요한 작업을 수행
5. 상태 업데이트 → API 서버: 필요한 리소스 생성/변경을 수행한 뒤, .status 업데이트를 위해 API 서버에 POST/PUT 요청을 보냄

Reference

• https://www.cncf.io/blog/2022/06/15/kubernetes-operators-what-are-they-some-examples/

Kubernetes Operators: what are they? Some examples

• https://techblog.lycorp.co.jp/ko/define-and-manage-kubernetes-custom-resources-with-controller

쿠버네티스 커스텀 리소스 정의하고 관리하기(feat.컨트롤러)

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

오퍼레이터(operator) 패턴