Operator パターン

Operator パターンとは

Operator パターンは、Kubernetes のカスタムリソース (CRD) とカスタムコントローラーを組み合わせ、アプリケーションの運用 (デプロイ、スケーリング、バックアップ、アップグレード) を自動化するパターンである。CoreOS (現 Red Hat) が 2016 年 11 月に公開したブログ記事「Introducing Operators」で提唱した。

なぜ必要か

Deployment や StatefulSet が宣言できるのは、レプリカ数とコンテナイメージ、Pod の入れ替え順序までである。どのインスタンスが primary かを判定し、昇格させる前にレプリカの追従を待ち、追いついてから接続先を切り替える、といった手順の知識を書く場所がない。結果として、DB のフェイルオーバー、バックアップ、スキーママイグレーションは運用手順書と人の判断に残る。Operator はこの手順知識をコントローラーのコードへ移し、カスタムリソースの宣言だけで再現できる形にする。

仕組み

Operator の配備は、CRD (Custom Resource Definition) と、それを担当するコントローラーの 2 点セットで行う。CRD だけを入れてもカスタムリソースの型が増えるだけで何も起きず、コントローラーは通常 control plane の外側、つまりクラスター内の普通の Pod として動く。利用者側の操作はカスタムリソースを作る、書き換える、消すだけで、実際の作業はコントローラーが担う。

コントローラーの Reconciliation Loop は、イベントの差分を追いかけるのではなく、周回ごとに現状を読み直して望ましい状態と比べる。そのため通知を 1 回取りこぼしても次の周回で回復する。逆に同じ処理が何度も走る前提になるため、各アクションは冪等でなければならない。観測した結果はカスタムリソースの status へ書き戻し、削除時に外部リソース (バックアップ先のバケットやクラウドのロードバランサー) を片付ける必要があれば、finalizer を付けて後片付けが済むまで削除の完了を保留する。

1. CRD (Custom Resource Definition) でカスタムリソースを定義
   例: PostgresCluster

2. カスタムコントローラーが CRD を監視
   「PostgresCluster が作成された → PostgreSQL をデプロイ」
   「レプリカ数が変更された → スケーリング」
   「バージョンが変更された → ローリングアップグレード」

3. Reconciliation Loop
   現在の状態 → 望ましい状態 → 差分を検出 → アクションを実行

CRD の例

PostgreSQL を管理する Crunchy PGO では、版、インスタンス数、ボリューム、バックアップ先までを 1 つの宣言にまとめる。

apiVersion: postgres-operator.crunchydata.com/v1
kind: PostgresCluster
metadata:
  name: my-db
spec:
  postgresVersion: 16
  instances:
    - replicas: 3
      dataVolumeClaimSpec:
        accessModes: [ReadWriteOnce]
        resources:
          requests:
            storage: 20Gi
  backups:
    pgbackrest:
      configuration:
        - secret:
            name: pgo-s3-creds
      repos:
        - name: repo1
          s3:
            bucket: my-backups
            endpoint: s3.ap-northeast-1.amazonaws.com
            region: ap-northeast-1

この宣言が効くのは、対象の Operator (この例では PGO) が先にクラスターへ入っている場合だけである。未導入のクラスターに適用しても、PostgresCluster という種類を知らないと拒否されて終わる。バックアップも宣言だけでは足りず、接続先のエンドポイントとアクセスキーを収めた Secret を別に用意し、pgBackRest の設定として参照させる必要がある。ここまで揃っていれば、3 インスタンス構成の PostgreSQL とバックアップの経路がカスタムリソース 1 つの適用で組み上がる (2026 年 8 月時点の公式サンプルの構成)。

代表的な Operator

自分で書き始める前に、既存の Operator を探す方が早い場面が多い。運用の勘所が作者側で織り込まれているためである。

Operator	管理対象
Prometheus Operator	Prometheus + Alertmanager
Cert-Manager	TLS 証明書の自動発行・更新
Strimzi	Apache Kafka
Crunchy PGO	PostgreSQL
Redis Operator	Redis Cluster

Helm との違い

Helm と Operator は排他ではなく、Operator 自身の配布に chart を使う構成が一般的である。違いは、配置した後の運用まで面倒を見るかどうかに出る。

観点	Helm	Operator
目的	パッケージ管理 (インストール)	ライフサイクル管理 (運用)
Day 1 (初期構築)	Chart の値を差し替えて一度に配置する	カスタムリソースを 1 つ作れば配置が始まる
Day 2 (運用)	インストール後は関与せず、運用は人が行う	バックアップや版の更新を継続して実行する
自動修復	適用した時点の状態を流し込むだけで、その後のずれは検知しない	望ましい状態と現状を繰り返し比べ、ずれを戻す

EKS での Operator

EKS では AWS Load Balancer Controller、ExternalDNS、Karpenter (ノードオートスケーラー) が Operator パターンで実装されている。Karpenter は karpenter.sh/v1 の NodePool、AWS Load Balancer Controller は TargetGroupBinding という独自のカスタムリソースを持ち、宣言した内容に合わせて実体 (ノードの起動やターゲットグループへの登録) を作り続ける。ノードの増減や証明書の更新のように、従来は運用担当が手を動かしていた領域が宣言に置き換わっている。

自作する場合は Kubebuilder か Operator SDK (どちらも controller-runtime が土台) で骨格を生成し、Reconcile 関数の中身だけを書く形になる。実装で崩れやすいのは、処理が途中で失敗したときに例外で止めずに再キューへ回す部分と、コントローラーへ与える権限で、対象を絞らないとクラスター全体を触れる ServiceAccount ができあがる。運用側の落とし穴は CRD の削除で、型を消すと配下のカスタムリソースも一緒に消えるため、クラスターの整理でうっかり CRD を削ると管理対象の定義がまとめて失われる。

サイト情報