Kubernetes Operator Pattern (feat. 언제까지 Helm만 쓸래?)

🧐 들어가기전

Strimzi - Apache Kafka on Kubernetes

GitHub - strimzi/strimzi-kafka-operator: Apache Kafka® running on Kubernetes

 

최근 Kafka를 Strimzi로 구축하면서 기존의 Helm Chart가 아닌 Operator로 셋업하게 되었다. 처음에는 "둘 다 YAML 작성해서 apply 하는 건 똑같은데 뭐가 다르지?"라는 의문이 있었다. 직접 운영해보니 그 차이가 명확해졌다.

---

🔸 1. Operator Pattern이란

1.1 핵심 개념

Operator pattern

Kubernetes 공식 문서에 따르면, Operator는 Custom Resource를 사용하여 애플리케이션과 그 컴포넌트를 관리하는 소프트웨어 확장이다. Operator는 Kubernetes의 핵심 원칙, 특히 Control Loop를 따른다.

 

Operator Pattern을 이해하려면 네 가지 핵심 개념을 알아야 한다.

---

1.1.1 CRD (Custom Resource Definition)

CRD는 Kubernetes API를 확장하는 방법이다. 기본 리소스인 Pod, Service, Deployment 외에 새로운 리소스 타입을 정의할 수 있다.

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: kafkas.kafka.strimzi.io
spec:
  group: kafka.strimzi.io
  names:
    kind: Kafka
    plural: kafkas
  scope: Namespaced
  versions:
    - name: v1beta2
      served: true
      storage: true

이 CRD를 클러스터에 등록하면, 이제 Kafka라는 새로운 Kind를 사용할 수 있게 된다.

1.1.2 CR (Custom Resource)

CR은 CRD로 정의된 타입의 인스턴스다. 실제로 사용자가 선언하는 리소스가 된다.

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    version: 3.7.0
    replicas: 3
    listeners:
      - name: plain
        port: 9092
        type: internal
    storage:
      type: persistent-claim
      size: 100Gi
  zookeeper:
    replicas: 3
    storage:
      type: persistent-claim
      size: 100Gi

1.1.3 Custom Controller

Controller는 클러스터의 상태를 지속적으로 감시하면서 현재 상태(Current State)를 원하는 상태(Desired State)로 맞추는 역할을 한다. Kubernetes의 기본 Controller(예: Deployment Controller)와 동일한 방식으로 동작한다.

Controller는 Watch 메커니즘을 통해 CR의 변경을 감지하고, Reconcile 함수를 실행하여 상태를 동기화한다. 이 루프가 끊임없이 돌아가면서 시스템의 일관성을 유지한다.

1.1.4 Operator

Operator는 CRD와 Controller를 묶어서 특정 애플리케이션의 운영 지식(Operational Knowledge)을 코드로 구현한 것이다. 단순히 리소스를 생성하는 것을 넘어, 애플리케이션 레벨의 도메인 지식을 포함한다.

Strimzi의 경우, Operator가 Java로 작성되어 있다. CR에 정의된 스펙을 읽고, 그에 맞게 StatefulSet, Service, ConfigMap 등을 생성하고 관리한다. 직접 Operator를 만들 일은 거의 없겠지만, 동작 원리를 이해하면 트러블슈팅에 도움이 된다.

---

🔸 2. Helm Chart vs Operator

2.1 근본적인 차이

둘 다 Kubernetes에 애플리케이션을 배포하는 도구지만, 동작 방식이 근본적으로 다르다.

Helm은 클라이언트 사이드 도구다. 차트를 렌더링해서 YAML을 생성하고, kubectl apply와 동일하게 API 서버에 전달한다. 설치가 끝나면 Helm의 역할도 끝난다. 이후 리소스에 문제가 생겨도 Helm은 관여하지 않는다.

Operator는 클러스터 내부에서 실행되는 Controller다. CR이 생성되면 그 시점부터 지속적으로 리소스를 감시하고 관리한다. Pod가 죽으면 다시 살리고, 설정이 변경되면 Rolling Update를 수행한다.

---

2.2 설정 변경 시 동작 비교

Helm 방식에서 Kafka 브로커 수를 3개에서 5개로 늘리려면 다음 과정을 거친다.

# values.yaml 수정
# replicas: 3 -> replicas: 5

helm upgrade kafka bitnami/kafka -f values.yaml

Operator 방식에서는 CR만 수정하면 된다.

kubectl edit kafka my-cluster
# spec.kafka.replicas: 3 -> 5 로 수정 후 저장

표면적으로는 비슷해 보이지만, 내부 동작이 다르다. Helm은 단순히 새로운 YAML을 apply하는 것이고, Operator는 변경 사항을 감지하여 안전한 방식으로 스케일링을 수행한다.

Strimzi Overview (0.49.1)

Strimzi Operator의 경우, Kafka 브로커를 추가할 때 Cruise Control을 통해 파티션 재배치까지 자동으로 수행한다. Helm으로는 이런 애플리케이션 레벨의 작업을 자동화할 수 없다.

---

2.3 StatefulSet의 한계

여기서 한 가지 의문이 생긴다. StatefulSet도 Pod 순서 보장하고, PVC 유지하고, Rolling Update 해주는데 왜 Operator가 필요할까?

StatefulSet이 해주는 것은 Kubernetes 레벨의 작업이다.

• Pod 순서대로 생성 (kafka-0 → kafka-1 → kafka-2)
• 안정적인 네트워크 ID (kafka-0.kafka-headless.svc)
• PVC 유지 (Pod 재시작해도 데이터 보존)
• 롤링 업데이트 (Pod 하나씩 재시작)
• Pod 죽으면 재생성

StatefulSet이 해주지 않는 것은 애플리케이션 레벨의 작업이다.

• Kafka 파티션 리더가 누군지 모름
• 브로커가 정상적으로 클러스터에 조인했는지 모름
• 업그레이드 시 "이 브로커 재시작해도 되는지" 판단 못함
• 스케일링 시 파티션 재배치 안 함
• 토픽/사용자 생성 못함

StatefulSet은 "Pod가 Ready 상태인가?"만 확인하지, "Kafka 브로커가 ISR(In-Sync Replica)에 정상적으로 합류했는가?"는 확인하지 않는다. Operator는 이런 애플리케이션 수준의 health check를 수행한다.

---

🔸 3. Operator는 언제 쓰는가

3.1 복잡한 분산 시스템

Operator가 빛을 발하는 영역은 복잡한 분산 시스템이다. Kafka, Elasticsearch, PostgreSQL 같은 스테이트풀 애플리케이션이 대표적이다.

Helm으로 Kafka 토픽을 생성하려면 클러스터에 직접 접속해야 한다.

# Kafka 클러스터에 직접 접속
kubectl exec -it kafka-0 -- bash

# 토픽 생성
kafka-topics.sh --create --topic new-topic \
  --bootstrap-server kafka:9092 \
  --partitions 3 --replication-factor 2

# 설정 변경
kafka-configs.sh --alter --topic new-topic \
  --add-config retention.ms=604800000 \
  --bootstrap-server kafka:9092

이 설정은 Helm이 관리하지 않는다. Git에 저장할 수도 없고, GitOps도 불가능하다.

 

Operator 방식에서는 YAML로 선언한다.

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  name: new-topic
  labels:
    strimzi.io/cluster: my-cluster
spec:
  partitions: 3
  replicas: 2
  config:
    retention.ms: "604800000"

kubectl apply -f topic.yaml

이제 토픽 설정도 Git에 저장되고, PR 리뷰를 거치고, ArgoCD로 자동 배포할 수 있다. Infrastructure as Code의 범위가 애플리케이션 설정까지 확장된다.

---

3.2 Day 2 Operations 자동화

• Day 1 Operations는 설치다.
• Day 2 Operations는 운영이다.

백업, 복구, 업그레이드, 스케일링, 장애 대응 같은 작업이 Day 2에 해당한다.

Helm은 Day 1에 강하다. 설치는 쉽다. 하지만 Day 2부터는 수동 작업이 많아진다.

 

Operator는 Day 2를 자동화한다. Strimzi Operator가 제공하는 Day 2 기능을 보면 다음과 같다.

• Rolling Upgrade: Kafka 버전 업그레이드 시 브로커를 하나씩 안전하게 재시작
• Cruise Control 연동: 파티션 자동 재배치로 클러스터 밸런싱
• User/ACL 관리: KafkaUser CR로 사용자와 권한을 선언적으로 관리
• TLS 인증서 자동 갱신: 만료 전에 자동으로 인증서 로테이션

---

3.3 Operator가 필요 없는 경우

모든 애플리케이션에 Operator가 필요한 것은 아니다. Stateless 애플리케이션, 단순한 마이크로서비스, 짧은 수명의 배치 잡 같은 경우에는 Helm이나 Kustomize로 충분하다.

Operator를 도입하면 복잡도가 올라간다. Operator 자체도 Pod로 실행되므로 추가 리소스를 소비하고, 장애 포인트가 하나 더 생긴다. 단순한 애플리케이션에 Operator를 쓰는 것은 오버엔지니어링이다.

---

🔸 4. OperatorHub

OperatorHub.io | The registry for Kubernetes Operators

커뮤니티에서 만든 Operator를 찾아볼 수 있는 곳이 OperatorHub이다. CNCF 프로젝트들의 공식 Operator부터 벤더가 제공하는 상용 Operator까지 다양하게 등록되어 있다.

 

주요 Operator 목록을 보면 다음과 같다.

• Strimzi Kafka Operator: Kafka 클러스터 관리
• Prometheus Operator: 모니터링 스택 관리
• Cert-Manager: TLS 인증서 자동 발급 및 갱신
• Postgres Operator (Zalando): PostgreSQL 클러스터 관리
• Elasticsearch Operator (ECK): Elastic Stack 관리

직접 Operator를 만들 일은 드물지만, 필요하다면 Operator SDK나 Kubebuilder를 사용할 수 있다.

---

🪄 정리

Helm은 패키지 매니저다. 템플릿을 렌더링해서 YAML을 만들고, 설치 후에는 손을 뗀다. 단순한 Stateless 애플리케이션 배포에 적합하다.
Operator는 자동화된 운영자다. CR을 감시하면서 지속적으로 상태를 관리하고 애플리케이션 레벨의 운영 작업을 자동화한다. Kafka, PostgreSQL 같은 복잡한 분산 시스템에서 진가를 발휘한다.
둘은 상호 배타적이지 않다. 많은 팀이 Stateless 앱은 Helm으로, Stateful 인프라는 Operator로 관리하는 하이브리드 전략을 사용한다. Operator 자체도 Helm Chart로 설치하는 경우가 많다.
결국 "언제까지 Helm만 쓸래?"에 대한 답은 "Stateful 앱의 Day 2 Operations를 자동화하고 싶을 때"가 된다.

---

📙 출처

• Kubernetes 공식 문서 - Operator Pattern: https://kubernetes.io/docs/concepts/extend-kubernetes/operator/
• Strimzi 공식 문서: https://strimzi.io/docs/operators/latest/overview
• OperatorHub: https://operatorhub.io
• Kubebuilder: https://book.kubebuilder.io
• 조대협 블로그 - Kubernetes Operator: https://bcho.tistory.com/1391