쿠버네티스는 Deployment 하나면 웹 서버를 알아서 띄우고 죽으면 살립니다. 그런데 데이터베이스처럼 "백업하고, 마스터를 승격하고, 순서대로 업그레이드하라" 같은 운영 지식이 필요한 앱은 기본 리소스만으로 부족합니다. 오퍼레이터(Operator) 패턴은 이런 사람의 운영 노하우를 코드로 옮겨, 클러스터가 스스로 운영하게 만드는 방식입니다.
두 개의 축 — CRD와 컨트롤러
오퍼레이터는 두 부분으로 이루어집니다. 새로운 리소스 종류를 정의하는 CRD와, 그 리소스를 감시하며 실제 작업을 하는 컨트롤러입니다.
| 구성요소 | 역할 | 비유 |
|---|---|---|
| CRD | 새 리소스 타입 정의 | kind: PostgresCluster를 만들 수 있게 함 |
| CR(커스텀 리소스) | 원하는 상태 선언 | "노드 3개짜리 DB를 원한다" |
| 컨트롤러 | 선언을 실현 | CR을 보고 Pod·Service를 실제로 생성 |
| 조정 루프 | 차이를 메움 | 현재 상태와 원하는 상태를 계속 비교 |
CRD를 등록하면 kubectl get postgrescluster 처럼 기본 리소스가 아닌 것도 다룰 수 있게 됩니다. 그 리소스가 실제로 무슨 일을 하는지는 컨트롤러가 책임집니다.
조정 루프 — 오퍼레이터의 심장
컨트롤러는 멈추지 않고 돌면서 "선언된 상태(spec)"와 "실제 상태(status)"를 비교하고, 차이가 있으면 메웁니다. 이 반복을 조정 루프(reconcile loop)라고 합니다.
apiVersion: db.example.com/v1
kind: PostgresCluster
metadata:
name: orders-db
spec:
replicas: 3
version: "16"
backup:
schedule: "0 2 * * *"
이 YAML 한 장을 적용하면, 컨트롤러가 Pod 3개와 백업 CronJob을 만들고, 노드가 하나 죽으면 새로 띄우며, version을 바꾸면 순서대로 업그레이드합니다. 사람이 매번 하던 절차가 코드 안으로 들어간 것입니다.
kubectl get crd
kubectl get postgrescluster orders-db -o yaml
kubectl describe postgrescluster orders-db
언제 오퍼레이터가 필요한가
모든 앱에 오퍼레이터가 필요하진 않습니다. 상태가 없는 웹 서버는 Deployment로 충분합니다. 오퍼레이터는 백업·장애 복구·순차 업그레이드처럼 운영 절차가 복잡한 스테이트풀 앱에서 빛을 냅니다.
요점 정리
- 오퍼레이터는 사람의 운영 노하우를 컨트롤러 코드로 옮긴 패턴이다.
- CRD로 새 리소스 타입을 정의하고, 커스텀 리소스로 원하는 상태를 선언한다.
- 컨트롤러의 조정 루프가 선언과 실제의 차이를 끊임없이 메운다.
- 백업·복구가 복잡한 스테이트풀 앱에 특히 유용하다.
CRD와 컨트롤러가 협력하는 과정을 직접 리소스를 만들며 확인하는 실습은 쿠버네티스 트랙에서 할 수 있습니다 — 회원가입 없이 무료로.