- Authors

- Name
- Youngju Kim
- @fjvbn20031
- 들어가며 — Operator는 도대체 무엇을 자동화하는가
- Operator의 기본 동작 원리 (3분 복습)
- 1. 데이터베이스 — Operator가 가장 빛나는 영역
- 2. 메시징 — Strimzi (Apache Kafka)
- 3. 캐시 — Redis Operator
- 4. 모니터링 — Prometheus Operator
- 5. 인증서 — cert-manager
- 6. 시크릿 — External Secrets Operator
- 7. GitOps — Argo CD
- 8. 백업 — Velero
- 9. 서비스메시 — Istio
- 10. 머신러닝 — Kubeflow
- 비교 테이블 — 무엇을 자동화하고, 얼마나 성숙한가
- 직접 만들 만한 사내 Operator 아이디어 10선
- 만들 가치가 있는가 — 판단 기준
- 기성 Operator를 고를 때 보는 것
- 마치며
- 참고 자료
들어가며 — Operator는 도대체 무엇을 자동화하는가
쿠버네티스를 어느 정도 다뤄 본 사람이라면 "Operator"라는 단어를 수없이 들었을 것입니다. 그런데 막상 "Operator가 뭐냐"고 물으면 "CRD랑 컨트롤러"라는 추상적인 답만 돌아옵니다. 정의는 맞지만, 그것이 실제로 무슨 문제를 해결하는지는 잘 와닿지 않습니다.
이 글은 정의 대신 사례로 접근합니다. 데이터베이스, 메시징, 캐시, 모니터링, 인증서, 시크릿, GitOps, 백업, 서비스메시, 머신러닝까지 — 현업에서 가장 널리 쓰이는 Operator들을 영역별로 정리하고, 각각이 어떤 운영 노동을 코드로 대체했는지를 구체적으로 보여 드립니다. 이 카탈로그를 다 읽고 나면 "아, Operator는 이런 데 쓰는 거구나"라는 감각이 손에 잡힐 것입니다.
핵심부터 말하면, Operator의 본질은 사람 운영자(operator)의 지식을 코드로 옮긴 것입니다. "Postgres 마스터가 죽으면 레플리카를 승격시키고, DNS를 갱신하고, 백업을 확인한다" 같은 절차를 사람이 새벽에 깨어나 수행하는 대신, 컨트롤러가 reconcile 루프에서 자동으로 수행합니다. 그래서 데이터베이스, 메시지 브로커처럼 상태가 있고 운영 절차가 복잡한 시스템일수록 Operator의 가치가 커집니다.
Operator의 기본 동작 원리 (3분 복습)
본격적인 사례에 들어가기 전에, 모든 Operator가 공유하는 동작 원리를 짧게 정리합니다.
사용자가 CR(Custom Resource)을 선언
|
v
+------------------------+
| Operator(컨트롤러) |
| reconcile 루프 |
| desired vs actual 비교 |
+-----------+------------+
|
v 부족한 것 생성/수정/삭제
+------------------------+
| StatefulSet / Service |
| ConfigMap / PVC / Job |
| (실제 쿠버네티스 리소스) |
+------------------------+
사용자는 "Postgres 클러스터, 레플리카 3개, 버전 16, 매일 백업"이라고 **원하는 상태(desired state)**만 선언합니다. Operator는 현재 상태(actual state)를 관찰하고, 둘 사이의 차이를 메우는 행동을 합니다. 이 루프가 멱등(idempotent)하게, 반복적으로 돌면서 시스템을 선언된 상태로 수렴시킵니다.
이 모델이 강력한 이유는 장애 복구가 공짜로 따라오기 때문입니다. 레플리카가 죽어 actual이 2개가 되면, 다음 reconcile에서 차이를 발견하고 다시 3개로 만듭니다. 사람이 개입할 필요가 없습니다.
1. 데이터베이스 — Operator가 가장 빛나는 영역
상태 저장 데이터베이스는 Operator의 킬러 애플리케이션입니다. 백업, 복구, 페일오버, 스케일, 버전 업그레이드 — 모두 까다롭고 위험한 운영 작업이고, 바로 그래서 자동화의 가치가 가장 큽니다.
CloudNativePG (PostgreSQL)
CloudNativePG는 CNCF 샌드박스 프로젝트로, "쿠버네티스 네이티브하게" Postgres를 운영하도록 설계됐습니다. StatefulSet을 쓰지 않고 직접 파드를 관리하는 점이 특징인데, 이는 페일오버 시 더 정밀한 제어를 위해서입니다.
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
name: pg-prod
spec:
instances: 3
imageName: ghcr.io/cloudnative-pg/postgresql:16.3
storage:
size: 100Gi
backup:
barmanObjectStore:
destinationPath: s3://my-backups/pg-prod
s3Credentials:
accessKeyId:
name: backup-creds
key: ACCESS_KEY_ID
secretAccessKey:
name: backup-creds
key: SECRET_ACCESS_KEY
retentionPolicy: "30d"
이 한 장의 YAML이 자동화하는 것: 프라이머리 1대 + 레플리카 2대 구성, 스트리밍 복제 설정, 프라이머리 장애 시 자동 페일오버(레플리카 승격), S3로의 지속적 백업(WAL 아카이빙), 30일 보존 정책. 사람이 손으로 하던 모든 절차가 선언으로 바뀝니다.
Zalando Postgres Operator
Zalando가 자사 수천 개 Postgres 클러스터를 운영하며 만든 Operator입니다. Patroni(HA 솔루션)를 내장하고, 매니페스트가 간결한 것이 장점입니다.
apiVersion: acid.zalan.do/v1
kind: postgresql
metadata:
name: acid-minimal-cluster
spec:
teamId: "acid"
numberOfInstances: 2
postgresql:
version: "16"
volume:
size: 10Gi
Vitess (MySQL 샤딩)
Vitess는 MySQL을 수평 샤딩해 페타바이트급으로 확장하는 시스템으로, YouTube에서 시작됐습니다. Vitess Operator는 샤드, 셀(cell), 태블릿(tablet) 같은 Vitess 고유 개념을 CRD로 노출합니다. 단일 MySQL로는 감당 못 하는 규모에서 빛납니다.
2. 메시징 — Strimzi (Apache Kafka)
Kafka를 직접 운영해 본 사람은 압니다. 브로커, 주키퍼(또는 KRaft), 토픽, 파티션, 리밸런싱, 롤링 업그레이드 — 무엇 하나 쉬운 게 없습니다. Strimzi는 이 모든 것을 CRD로 추상화합니다.
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
name: my-cluster
spec:
kafka:
version: 3.9.0
replicas: 3
listeners:
- name: tls
port: 9093
type: internal
tls: true
config:
offsets.topic.replication.factor: 3
min.insync.replicas: 2
storage:
type: persistent-claim
size: 100Gi
entityOperator:
topicOperator: {}
userOperator: {}
흥미로운 점은 Strimzi가 Operator 안에 또 다른 Operator를 품는다는 것입니다. Topic Operator와 User Operator가 그것인데, 토픽조차 CRD로 선언합니다.
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
name: orders
labels:
strimzi.io/cluster: my-cluster
spec:
partitions: 12
replicas: 3
config:
retention.ms: 604800000
토픽 생성을 GitOps로 관리할 수 있게 되는 것입니다. "토픽 추가 = PR 머지"가 됩니다.
3. 캐시 — Redis Operator
Redis도 단독 인스턴스를 넘어 Sentinel 기반 HA나 Cluster 모드 샤딩으로 가면 운영이 급격히 복잡해집니다. 여러 Redis Operator(예: Spotahome, OT-CONTAINER-KIT)가 이를 자동화합니다.
apiVersion: databases.spotahome.com/v1
kind: RedisFailover
metadata:
name: redisfailover
spec:
sentinel:
replicas: 3
redis:
replicas: 3
storage:
persistentVolumeClaim:
metadata:
name: redisfailover-data
spec:
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 10Gi
Sentinel 3대가 마스터를 감시하다가 장애를 감지하면 레플리카를 승격시키고, 애플리케이션은 Sentinel에 물어 새 마스터를 찾습니다. 이 페일오버 오케스트레이션 전체를 Operator가 책임집니다.
4. 모니터링 — Prometheus Operator
Prometheus Operator는 가장 널리 쓰이는 Operator 중 하나입니다. kube-prometheus-stack의 핵심으로, Prometheus 설정 파일을 직접 만지는 대신 CRD로 모니터링 대상을 선언하게 합니다.
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: my-app
labels:
release: kube-prometheus-stack
spec:
selector:
matchLabels:
app: my-app
endpoints:
- port: metrics
interval: 30s
path: /metrics
ServiceMonitor를 만들면 Operator가 Prometheus의 scrape 설정을 자동 갱신합니다. 알림 규칙도 PrometheusRule CRD로 선언합니다.
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: my-app-rules
spec:
groups:
- name: my-app
rules:
- alert: HighErrorRate
expr: rate(http_requests_total{code=~"5.."}[5m]) > 0.05
for: 10m
labels:
severity: critical
annotations:
summary: "5xx error rate is high"
알림 규칙이 코드로 버전 관리되고, 애플리케이션 배포와 함께 알림 설정이 따라가는 패턴이 가능해집니다.
5. 인증서 — cert-manager
cert-manager는 TLS 인증서의 발급·갱신·배포를 자동화합니다. Let's Encrypt(ACME), Vault, 사내 CA 등 다양한 발급자를 지원하고, 인증서 만료 전 자동 갱신이 핵심 가치입니다.
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: example-tls
spec:
secretName: example-tls-secret
dnsNames:
- app.example.com
issuerRef:
name: letsencrypt-prod
kind: ClusterIssuer
"인증서 갱신 깜빡해서 사이트가 죽는" 고전적 사고를 cert-manager가 근절합니다. Certificate를 선언하면 Operator가 ACME 챌린지를 수행하고, Secret에 인증서를 채우고, 만료 전 갱신까지 알아서 합니다.
6. 시크릿 — External Secrets Operator
시크릿을 Git에 평문으로 넣을 수는 없습니다. External Secrets Operator(ESO)는 AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager 같은 외부 저장소의 시크릿을 쿠버네티스 Secret으로 동기화합니다.
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: db-credentials
spec:
refreshInterval: 1h
secretStoreRef:
name: aws-secrets-manager
kind: SecretStore
target:
name: db-credentials
data:
- secretKey: password
remoteRef:
key: prod/db/password
Git에는 "어떤 시크릿을 가져올지"만 선언하고, 실제 값은 외부 금고에 둡니다. Operator가 주기적으로 동기화하므로 외부에서 시크릿을 회전(rotation)하면 자동으로 반영됩니다.
7. GitOps — Argo CD
Argo CD 자체가 Operator 패턴으로 동작합니다. Application CRD가 "어떤 Git 저장소의 어떤 경로를 어떤 클러스터에 동기화할지"를 선언합니다.
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-app
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/my-org/my-app-config
targetRevision: main
path: overlays/prod
destination:
server: https://kubernetes.default.svc
namespace: my-app
syncPolicy:
automated:
prune: true
selfHeal: true
selfHeal이 켜져 있으면, 누군가 클러스터에서 수동으로 리소스를 바꿔도 Argo CD가 Git 상태로 되돌립니다. Git이 단일 진실 공급원(single source of truth)이 되는 것입니다.
8. 백업 — Velero
Velero는 클러스터 리소스와 퍼시스턴트 볼륨을 백업·복구합니다. Backup, Restore, Schedule 같은 CRD를 제공합니다.
apiVersion: velero.io/v1
kind: Schedule
metadata:
name: daily-backup
namespace: velero
spec:
schedule: "0 2 * * *"
template:
includedNamespaces:
- production
storageLocation: aws-s3
ttl: 720h0m0s
매일 새벽 2시에 production 네임스페이스를 백업하고 30일간 보존합니다. 클러스터 마이그레이션이나 DR 시나리오의 핵심 도구입니다.
9. 서비스메시 — Istio
Istio는 사이드카(또는 ambient 모드)로 트래픽을 가로채 라우팅, mTLS, 관측을 제공합니다. VirtualService, DestinationRule, Gateway 같은 CRD로 트래픽 정책을 선언합니다.
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
weight: 90
- destination:
host: reviews
subset: v2
weight: 10
카나리 배포를 "트래픽 90 대 10"이라고 선언하면 메시가 그대로 만들어 줍니다. Istiod가 이 CRD들을 Envoy 설정으로 변환하는 컨트롤러 역할을 합니다.
10. 머신러닝 — Kubeflow
Kubeflow는 ML 워크플로를 쿠버네티스 위에서 운영하는 플랫폼이고, 여러 Operator의 집합체입니다. 대표적으로 Training Operator가 분산 학습 작업을 CRD로 다룹니다.
apiVersion: kubeflow.org/v1
kind: PyTorchJob
metadata:
name: pytorch-dist
spec:
pytorchReplicaSpecs:
Master:
replicas: 1
template:
spec:
containers:
- name: pytorch
image: my-registry/pytorch-train:latest
Worker:
replicas: 4
template:
spec:
containers:
- name: pytorch
image: my-registry/pytorch-train:latest
분산 학습의 마스터-워커 토폴로지 구성, 환경 변수 주입(RANK, WORLD_SIZE 등), 실패한 워커 재시작을 Operator가 담당합니다. 데이터 과학자는 인프라를 몰라도 분산 학습을 돌릴 수 있게 됩니다.
비교 테이블 — 무엇을 자동화하고, 얼마나 성숙한가
CNCF Operator Capability Level은 Operator의 성숙도를 5단계로 나눕니다. Level 1(기본 설치)부터 Level 5(자동 파일럿: 오토스케일·자동 튜닝·이상 감지)까지입니다.
| Operator | 영역 | 핵심 자동화 | 대표 CRD | 성숙도 경향 |
|---|---|---|---|---|
| CloudNativePG | 데이터베이스 | 페일오버, 백업, PITR | Cluster | Level 4~5 |
| Zalando Postgres | 데이터베이스 | HA(Patroni), 복제 | postgresql | Level 4 |
| Vitess | 데이터베이스 | 샤딩, 수평확장 | VitessCluster | Level 4~5 |
| Strimzi | 메시징 | 브로커, 토픽, 업그레이드 | Kafka, KafkaTopic | Level 4~5 |
| Redis Operator | 캐시 | Sentinel 페일오버 | RedisFailover | Level 3~4 |
| Prometheus | 모니터링 | scrape 설정, 알림 | ServiceMonitor | Level 4 |
| cert-manager | 인증서 | 발급, 자동 갱신 | Certificate | Level 5 |
| External Secrets | 시크릿 | 외부 금고 동기화 | ExternalSecret | Level 4 |
| Argo CD | GitOps | 동기화, selfHeal | Application | Level 4 |
| Velero | 백업 | 스케줄 백업, 복구 | Schedule, Backup | Level 4 |
| Istio | 서비스메시 | 트래픽, mTLS | VirtualService | Level 4 |
| Kubeflow Training | ML | 분산학습 오케스트레이션 | PyTorchJob | Level 3~4 |
성숙도는 절대적 등급이 아니라 경향임에 유의하시기 바랍니다. 같은 Operator도 어떤 기능을 쓰느냐에 따라 체감 레벨이 다릅니다.
직접 만들 만한 사내 Operator 아이디어 10선
기성 Operator를 쓰는 것을 넘어, 조직 고유의 운영 지식을 Operator로 코드화할 수도 있습니다. 사내에서 만들어 볼 만한 아이디어를 정리합니다.
1. 온보딩 Operator
- Tenant CR 하나로 네임스페이스 + RBAC + 쿼터 + 기본 NetworkPolicy 일괄 생성
2. 인증서/도메인 Operator
- 내부 서비스 등록 시 DNS 레코드 + 인증서 + Ingress를 묶어 프로비저닝
3. 비용 라벨 강제 Operator
- cost-center 라벨 없는 워크로드를 거부하거나 자동 태깅
4. 야간 절전 Operator
- dev 네임스페이스를 업무 외 시간에 replicas=0으로 스케일 다운
5. 데이터베이스 셀프서비스 Operator
- DevDatabase CR로 격리된 테스트 DB를 즉석 생성/만료 삭제
6. 시크릿 회전 Operator
- 사내 정책에 맞춰 API 키를 주기적으로 회전하고 워크로드 롤링 재시작
7. 백업 검증 Operator
- 백업을 임시 클러스터에 복원해 무결성을 자동 검증
8. 카나리 분석 Operator
- 배포 후 메트릭을 평가해 자동 승격 또는 롤백
9. 컴플라이언스 스캔 Operator
- 이미지 취약점 스캔 결과를 CR status로 노출하고 정책 위반 차단
10. 멀티클러스터 배포 Operator
- PlacementPolicy CR로 워크로드를 여러 클러스터에 분배
이 아이디어들의 공통점은 반복적이고, 절차가 명확하며, 사람이 실수하기 쉬운 운영 작업이라는 점입니다. 바로 그 지점이 Operator의 스위트 스팟입니다.
만들 가치가 있는가 — 판단 기준
기성 Operator가 있는데 직접 만들면 낭비이고, 만들 가치가 없는데 만들면 유지보수 부채가 됩니다. 다음 기준으로 판단하시기 바랍니다.
[직접 만들 가치가 높은 신호]
- 운영 절차가 명확하고 반복적이다 (런북이 이미 존재한다)
- 그 절차를 사람이 자주 실수한다 (새벽 대응, 휴먼 에러)
- 조직 고유의 도메인이라 기성 Operator가 없다
- 선언적으로 표현하기 자연스럽다 (desired state가 명확)
- reconcile로 수렴 가능하다 (멱등하게 만들 수 있다)
[직접 만들지 말아야 할 신호]
- 일회성 작업이다 (Job이나 스크립트로 충분)
- 절차가 매번 사람의 판단을 요구한다 (자동화 위험)
- 이미 성숙한 기성 Operator가 있다 (cert-manager를 재발명하지 말 것)
- 상태가 없고 reconcile할 것이 없다 (그냥 웹훅이나 컨트롤러로 충분)
- 팀에 컨트롤러 운영 역량이 없다 (방치되면 부채)
특히 마지막 항목이 중요합니다. Operator는 만드는 것보다 장기 유지보수가 어렵습니다. CRD 버전 관리, 쿠버네티스 버전 업그레이드 대응, reconcile 버그로 인한 대량 리소스 오작동 위험까지 — 주인 없는 Operator는 시한폭탄이 됩니다.
기성 Operator를 고를 때 보는 것
직접 만들지 않고 기성 Operator를 도입할 때는 다음을 확인하시기 바랍니다.
| 확인 항목 | 왜 중요한가 |
|---|---|
| CNCF/공식 여부 | 거버넌스와 지속성의 신호 |
| 릴리스 주기 | K8s 신버전 대응이 빠른가 |
| Capability Level | 페일오버/백업까지 자동화하는가 |
| CRD 버전 정책 | v1alpha1에 머물러 있지 않은가 |
| 보안 (RBAC 범위) | 클러스터 어드민을 통째로 요구하지 않는가 |
| 운영 사례 | 대규모 프로덕션 레퍼런스가 있는가 |
마치며
Operator를 한 문장으로 요약하면 **"운영 지식을 reconcile 루프에 담은 것"**입니다. 데이터베이스의 페일오버, 인증서의 자동 갱신, 시크릿의 동기화 — 전부 예전엔 사람이 새벽에 깨어 하던 일이었고, 이제는 컨트롤러가 묵묵히 합니다.
이 카탈로그에서 한 가지만 가져간다면, "내 조직에서 가장 자주 반복되고 가장 자주 실수하는 운영 절차는 무엇인가"라는 질문이었으면 합니다. 그 답이 명확하고 선언적으로 표현 가능하다면, 그것이 바로 당신이 만들 첫 Operator의 후보입니다. 다음 글에서는 그중에서도 가장 도전적인 데이터베이스 Operator를 직접 만들어 보겠습니다.
참고 자료
- Kubernetes Operator 패턴 공식 문서: https://kubernetes.io/docs/concepts/extend-kubernetes/operator/
- Operator Framework: https://sdk.operatorframework.io/
- OperatorHub.io(Operator 카탈로그): https://operatorhub.io/
- CloudNativePG: https://cloudnative-pg.io/
- Zalando Postgres Operator: https://github.com/zalando/postgres-operator
- Vitess: https://vitess.io/
- Strimzi(Kafka Operator): https://strimzi.io/
- Prometheus Operator: https://prometheus-operator.dev/
- cert-manager: https://cert-manager.io/
- External Secrets Operator: https://external-secrets.io/
- Argo CD: https://argo-cd.readthedocs.io/
- Velero: https://velero.io/
- Istio: https://istio.io/latest/docs/
- Kubeflow Training Operator: https://www.kubeflow.org/docs/components/training/
- Operator Capability Levels: https://sdk.operatorframework.io/docs/overview/operator-capabilities/