単なるStatefulSetの適用だけでは、本番環境におけるデータベース運用は完結しません。ポッドの起動順序や永続ボリュームのマウントといった基本的なオーケストレーションはKubernetesが担当しますが、リーダー選出の失敗、スキーママイグレーションの同期、あるいは深夜3時の障害復旧といった「アプリケーション固有のドメイン知識」は、標準リソースには欠落しています。本稿では、Go言語とOperator SDKを用いたカスタムコントローラーの実装戦略について、内部アーキテクチャの観点から論じます。
1. Reconcile Loopの深層と冪等性
Operatorパターンの核心は、現在のクラスター状態（Current State）をユーザーが定義した望ましい状態（Desired State）に近づけ続ける無限ループ、すなわちReconciliation Loop（調整ループ）にあります。これは命令型（Imperative）なスクリプト実行とは根本的に異なります。
命令型アプローチでは「バックアップを実行せよ」という一度きりの指示を送りますが、Operatorは「バックアップポリシーが有効であるか」を常に監視します。実装において最も重要なのは、このループの冪等性（Idempotency）を保証することです。Reconcile関数はネットワークエラーやPodの再起動により、同じイベントに対して複数回呼び出される可能性があります。したがって、リソース作成処理は常に「存在確認（Check existence）」から始まる必要があり、副作用を制御しなければなりません。
2. Custom Resource Definition (CRD) の設計戦略
CRDは単なる設定ファイルではなく、APIスキーマです。PostgreSQL Operatorの活用事例などを参照すると、優れたCRD設計には以下の共通点が見られます。
- Statusサブリソースの活用:
spec（ユーザーの要求）とstatus（システムの現在地）を明確に分離します。Operatorはstatusを更新することで進行状況を報告し、外部システムはその値を監視します。 - Finalizersによるリソース管理: 外部リソース（例: AWS RDSインスタンスやS3バケット）を作成した場合、CR削除時にこれらが孤立（Orphaned）しないよう、Finalizerを用いてクリーンアップロジックを強制的に介入させる必要があります。
GoによるReconcileロジックの実装例
以下は、Kubernetes Operator SDKを使用した基本的なReconcile関数の構造です。エラーハンドリングとContextの伝播、およびリソース取得失敗時の分岐処理に注目してください。
// Reconcile is part of the main kubernetes reconciliation loop
func (r *DatabaseReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
log := log.FromContext(ctx)
// 1. Fetch the Custom Resource instance
dbInstance := &mydbv1.Database{}
if err := r.Get(ctx, req.NamespacedName, dbInstance); err != nil {
if client.IgnoreNotFound(err) != nil {
// Error reading the object - requeue the request.
log.Error(err, "Failed to get Database instance")
return ctrl.Result{}, err
}
// Resource not found (deleted). Stop reconciliation.
return ctrl.Result{}, nil
}
// 2. Business Logic: Check if StatefulSet exists
foundStatefulSet := &appsv1.StatefulSet{}
err := r.Get(ctx, types.NamespacedName{Name: dbInstance.Name, Namespace: dbInstance.Namespace}, foundStatefulSet)
if err != nil && errors.IsNotFound(err) {
// Define a new StatefulSet
dep := r.deploymentForDatabase(dbInstance)
log.Info("Creating a new StatefulSet", "StatefulSet.Namespace", dep.Namespace, "StatefulSet.Name", dep.Name)
if err = r.Create(ctx, dep); err != nil {
log.Error(err, "Failed to create new StatefulSet")
return ctrl.Result{}, err
}
// Requeue to ensure state is settled
return ctrl.Result{Requeue: true}, nil
} else if err != nil {
log.Error(err, "Failed to get StatefulSet")
return ctrl.Result{}, err
}
// 3. Update Status (Observe phase)
// Compare spec size with actual replicas, update status, etc.
return ctrl.Result{}, nil
}
3. HelmチャートとOperatorの比較と共存
多くのエンジニアが「HelmかOperatorか」という二元論に陥りがちですが、これらは対立する技術ではなく、補完関係にあります。Helmはパッケージングと初期デプロイ（Day 1 Operation）に強みを持ち、Operatorは継続的な運用管理（Day 2 Operation）に特化しています。
| 機能 | Helm Charts | Kubernetes Operator |
|---|---|---|
| 主な役割 | テンプレート化とパッケージ配布 | ライフサイクル管理と運用自動化 |
| ロジックの複雑さ | 限定的 (Go templates) | 無制限 (Go/Java/Python等の全機能) |
| 状態監視 | なし (Fire and forget) | あり (Reconcile loopによる常時監視) |
| 自動復旧 | K8sの標準機能に依存 | アプリケーション固有の復旧手順を実装可能 |
4. K8sクラスター内の自動バックアップと復旧の実装
ステートフルアプリケーション管理において最も複雑なのが、バックアップとリストアの自動化です。単にCronJobを作成するだけでは不十分です。Operatorは以下のような高度な制御を行う必要があります。
- 静止点の確保: ファイルシステムレベルのスナップショットではなく、データベースエンジンの
FLUSH TABLES WITH READ LOCKなどを実行し、整合性を保った状態でバックアップを取得する。 - Point-in-Time Recovery (PITR): WAL（Write Ahead Log）のアーカイブと連携し、特定時点への復旧を自動化するロジックをOperatorに組み込む。
- Leader Electionとの連携: バックアップ処理は通常、Read ReplicaやStandbyノードで実行し、Primaryノードの負荷を軽減すべきです。Operatorは現在のリーダーを選出し、適切なPodに対してバックアップコマンドを発行する役割を担います。
結論: 複雑性と自動化のトレードオフ
Operatorの導入は、開発とメンテナンスのコスト（Engineering Overhead）を増大させます。単純なCRUDアプリやステートレスなサービスに対してOperatorを開発することは、オーバーエンジニアリングです。しかし、データベース、分散ストレージ、メッセージキューといった複雑なステートを持つミドルウェアをKubernetes上で運用する場合、Operatorは人間の介入を最小限に抑え、SLAを維持するための唯一の現実的な解となります。導入に際しては、既存のOSS Operator（例: Prometheus Operator, Postgres Operator）の成熟度を評価し、不足機能がある場合にのみ自社開発を行う判断が推奨されます。
Post a Comment