Kubernetes의 StatefulSet 리소스만으로는 프로덕션 환경의 데이터베이스나 메시지 큐 시스템을 완벽하게 운영할 수 없습니다. StatefulSet은 파드(Pod)의 순차적 배포와 안정적인 네트워크 식별자(Stable Network ID)를 보장하지만, 리더 선출(Leader Election), 스키마 마이그레이션, 장애 조치(Failover), 그리고 시점 복구(PITR)와 같은 애플리케이션 고유의 도메인 지식을 이해하지 못하기 때문입니다. 이러한 "Day 2 Operation"의 복잡성은 결국 휴먼 에러를 유발하는 병목 지점이 됩니다. 오퍼레이터(Operator) 패턴은 이러한 운영 지식을 소프트웨어로 코딩하여 컨트롤러에 내재화하는 유일한 아키텍처적 해법입니다.
1. StatefulSet의 한계와 오퍼레이터의 필요성
데이터베이스와 같은 상태 저장(Stateful) 애플리케이션을 운영할 때 가장 큰 도전 과제는 인프라의 생명주기와 애플리케이션 데이터의 생명주기가 일치하지 않는다는 점입니다. 단순히 파드를 재시작하는 것만으로는 깨진 복제(Replication) 관계를 복구하거나, 손상된 WAL(Write-Ahead Log) 파일을 처리할 수 없습니다.
쿠버네티스 오퍼레이터는 Custom Resource Definition (CRD)와 Custom Controller의 조합입니다. CRD가 개발자가 정의한 스키마(예: PostgresCluster)를 API 서버의 일급 객체로 등록하면, 컨트롤러는 이 리소스의 상태를 감시(Watch)하고 실제 상태(Current State)를 의도한 상태(Desired State)로 일치시키는 조정 루프(Reconciliation Loop)를 수행합니다.
2. Helm 차트와 오퍼레이터의 결정적 차이
많은 엔지니어들이 Helm과 오퍼레이터를 혼동하거나 상호 배타적인 도구로 인식합니다. 그러나 두 기술은 해결하고자 하는 문제 공간이 다릅니다. Helm은 패키징 및 템플릿 엔진으로, "설치(Installation)" 시점의 복잡성을 줄이는 데 최적화되어 있습니다. 반면 오퍼레이터는 "운영(Operation)" 시점의 상태 관리에 집중합니다.
| 구분 | Helm Chart | Kubernetes Operator |
|---|---|---|
| 주요 목적 | 패키징, 템플릿 렌더링, 초기 배포 | 상태 감시, 자동 복구, 로직 수행 |
| 동작 방식 | Fire and Forget (배포 후 관여 안 함) | Active Reconciliation (지속적 루프) |
| 복잡도 | YAML 템플릿 관리 수준 | Go/Java 등 프로그래밍 언어 개발 필요 |
| 적합한 사례 | Stateless 웹 서버, CI/CD 도구 설치 | DB 클러스터, 분산 스토리지, 모니터링 시스템 |
PostgreSQL 오퍼레이터 활용 사례를 예로 들면, Helm은 초기 DB 인스턴스와 서비스를 생성할 수 있지만, 마스터 노드 장애 시 새로운 리더를 선출하고 복제본을 재구성하는 로직은 수행할 수 없습니다. 오퍼레이터는 이러한 상황을 감지하고 Failover 로직을 즉시 실행합니다.
3. 쿠버네티스 오퍼레이터 SDK 시작하기 및 핵심 구현
오퍼레이터 개발의 사실상 표준은 Go 언어 기반의 Operator SDK입니다. 핵심은 Reconcile 함수 구현에 있습니다. 이 함수는 클러스터의 특정 리소스에 변경 이벤트가 발생할 때마다 호출됩니다.
아래 코드는 CRD 객체의 Spec을 확인하고, 실제 리소스(예: Deployment)가 존재하지 않거나 Spec과 다를 경우 이를 생성/수정하는 idempotent(멱등성) 로직의 단순화된 형태입니다.
// Reconcile handles the reconciliation loop for the Custom Resource
// This logic must be idempotent.
func (r *MyDatabaseReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
log := log.FromContext(ctx)
// 1. Fetch the Custom Resource instance
dbInstance := &mydbv1alpha1.MyDatabase{}
if err := r.Get(ctx, req.NamespacedName, dbInstance); err != nil {
if errors.IsNotFound(err) {
// Resource deleted, stop reconciliation
return ctrl.Result{}, nil
}
return ctrl.Result{}, err
}
// 2. Define the desired Deployment object
desiredDep := r.deploymentForDatabase(dbInstance)
// 3. Check if the Deployment already exists
foundDep := &appsv1.Deployment{}
err := r.Get(ctx, types.NamespacedName{Name: dbInstance.Name, Namespace: dbInstance.Namespace}, foundDep)
if err != nil && errors.IsNotFound(err) {
// Create a new Deployment
log.Info("Creating a new Deployment", "Deployment.Namespace", desiredDep.Namespace, "Deployment.Name", desiredDep.Name)
err = r.Create(ctx, desiredDep)
if err != nil {
return ctrl.Result{}, err
}
// Deployment created successfully - return and requeue
return ctrl.Result{Requeue: true}, nil
} else if err != nil {
return ctrl.Result{}, err
}
// 4. Update logic (e.g., if replica count changed)
if *foundDep.Spec.Replicas != dbInstance.Spec.Size {
foundDep.Spec.Replicas = &dbInstance.Spec.Size
err = r.Update(ctx, foundDep)
if err != nil {
return ctrl.Result{}, err
}
}
return ctrl.Result{}, nil
}
Reconcile 함수 내에서 긴 시간이 소요되는 작업(예: 대용량 데이터베이스 백업)을 직접 동기적으로 실행하지 마십시오. 이는 컨트롤러 루프를 차단합니다. 대신 Kubernetes Job을 생성하고 해당 Job의 상태를 감시하는 비동기 패턴을 사용해야 합니다.
4. K8s 클러스터 내 자동 백업 및 복구 구현
상태 저장 애플리케이션의 오퍼레이터가 갖춰야 할 필수 기능은 자동 백업 및 복구입니다. 이를 구현하기 위해 별도의 CRD(예: DatabaseBackup)를 설계하는 것이 일반적입니다. 사용자가 DatabaseBackup 리소스를 생성하면, 오퍼레이터는 이를 감지하여 다음 워크플로우를 수행합니다.
- 스냅샷 트리거: 데이터베이스에
LOCK TABLES혹은 스냅샷 명령을 전송하여 일관성을 확보합니다. - 데이터 전송: PVC(Persistent Volume Claim)의 데이터를 압축하여 S3 호환 오브젝트 스토리지로 전송하는 임시 Pod(Job)를 실행합니다.
- 상태 업데이트: 백업 성공/실패 여부를
DatabaseBackup리소스의Status필드에 기록합니다. - 리소스 정리: 보존 정책(Retention Policy)에 따라 오래된 백업 CRD와 실제 스토리지 객체를 삭제합니다.
이 과정에서 오퍼레이터는 단순히 명령만 내리는 것이 아니라, 백업 Job이 OOMKilled 등으로 실패했을 때 재시도하거나 알림을 보내는 예외 처리 로직을 포함해야 합니다. 이는 쉘 스크립트나 CronJob만으로는 구현하기 어려운 수준의 견고함을 제공합니다.
결론
쿠버네티스 오퍼레이터는 단순한 자동화 도구가 아니라, SRE(Site Reliability Engineering)의 운영 지식을 코드베이스로 옮겨오는 핵심 아키텍처입니다. 특히 상태가 있는 애플리케이션을 관리할 때, StatefulSet의 부족한 부분을 오퍼레이터의 조정 루프로 채워야만 진정한 의미의 클라우드 네이티브 운영이 가능합니다. 초기 개발 비용(Development Overhead)은 높지만, 규모가 커질수록 운영 비용(Operational Cost)을 기하급수적으로 낮추는 Trade-off를 고려하여 도입을 결정하십시오.
Post a Comment