2026年5月26日

KubernetesのOperatorパターンとは｜カスタムリソースと調整ループの仕組み・使いどころ・作り方の入口

Docker・コンテナ

KubernetesのOperatorパターンは、データベースの構築やバックアップ、フェイルオーバーのような運用の手順を、カスタムリソース（CRD）とコントローラーの組み合わせとしてクラスターに組み込む設計です。利用者は「MySQLを3台構成で、毎日バックアップ」のような望む状態をYAMLで書き、Operatorがその状態に近づける作業を繰り返します。この記事では、Operatorを支える仕組み（CRD、調整ループ、ステータス、ファイナライザー）、HelmやStatefulSetとの違い、導入するか作るかの判断、Kubebuilderでの作り方の入口を説明します。

Operatorを構成する2つの部品

カスタムリソース（CRD）

Kubernetesには、DeploymentやServiceのような組み込みのリソースがあります。CustomResourceDefinition（CRD）を登録すると、これに加えて独自の種類のリソースをAPIに追加できます。たとえば次のようなリソースです。

apiVersion: db.example.com/v1alpha1
kind: MySQLCluster
metadata:
  name: wp-db
  namespace: wordpress
spec:
  replicas: 3
  version: "8.4"
  backup:
    schedule: "0 3 * * *"
status:
  readyReplicas: 3
  conditions:
    - type: Ready
      status: "True"

spec は利用者が書く「望む状態」、status はOperatorが書き込む「今の状態」です。CRDにはOpenAPIのスキーマで項目の型や必須項目を定義でき、間違った値は登録の時点で弾かれます。

コントローラー

CRDを登録しただけでは、リソースが保存されるだけで何も起きません。リソースの変化を監視して、実際にPodやServiceを作ったり、バックアップを実行したりするのがコントローラーです。KubernetesのDeploymentも、組み込みのコントローラーがReplicaSetとPodを管理することで動いています。Operatorは、この仕組みを特定のアプリ向けに作ったものと考えると分かりやすいです。

調整ループ（Reconcile）の考え方

コントローラーの中心は、調整（Reconcile）と呼ばれる処理です。リソースに変化があるたびに、次の流れを繰り返します。

カスタムリソースの spec（望む状態）を読む。
クラスターの実際の状態（StatefulSet、Service、Secretなど）を読む。
差があれば、作成・更新・削除して近づける。
結果を status に書き込む。

ここで大切なのは、「何が起きたか」ではなく「今どうなっているか」を見て判断することです。イベントを取りこぼしても、次の調整で差に気づいて直せます。そのため調整の処理は、何度実行しても同じ結果になる（冪等な）書き方にします。「作成する」ではなく「無ければ作り、あれば望む形に更新する」と書くのが基本です。

削除と後片付けの仕組み

Operatorが作ったリソースを、カスタムリソースの削除と一緒に消すには2つの仕組みを使います。

オーナー参照（ownerReferences）：作ったStatefulSetなどに「持ち主はこのMySQLCluster」と記録しておくと、持ち主が消えたときにKubernetesのガベージコレクションが自動で削除します。
ファイナライザー（finalizers）：クラウドのストレージやDNSのレコードなど、クラスターの外にあるものを消してから削除を完了したいときに使います。ファイナライザーが付いている間、リソースは削除中のまま残り、Operatorが後片付けを終えてファイナライザーを外すと消えます。

Operatorを先にアンインストールすると、ファイナライザーを外す担当がいなくなり、カスタムリソースが削除中のまま消えなくなります。Operatorを外すときは、カスタムリソースを先に削除し、消えたことを確認してからOperatorを外す順番にします。

Helm・StatefulSetとの違い

Helmは、テンプレートからマニフェストを作ってインストールやアップグレードをする道具です。インストールした後の運用（障害時の切り替え、定期バックアップ、版の上げ方の手順）は担いません。StatefulSetは、Podに固定の名前とボリュームを与えますが、「どれがプライマリか」「レプリケーションをどう組むか」といったアプリ固有の知識は持っていません。

Operatorは、その足りない部分、つまり運用担当者が手順書に沿って行っていた判断をコードにします。たとえばデータベースのOperatorなら、プライマリが落ちたときにレプリカを昇格させ、接続先のServiceを切り替える、といった処理を自動で行います。

逆に、設定ファイルとDeploymentだけで動くステートレスなアプリには、Operatorは過剰です。WordPress本体のようなWebアプリはDeploymentとHelmで十分なことが多く、Operatorの出番はその裏のデータベースや証明書の管理です。

代表的なOperator

cert-manager：TLS証明書の発行と更新を自動化する。
Prometheus Operator：Prometheusの構成や監視対象を、ServiceMonitorなどのカスタムリソースで管理する。
データベースのOperator：PostgreSQLのCloudNativePG、MySQLのPercona Operator や MySQL Operator for Kubernetes、KafkaのStrimziなど。

OperatorHub.io などのカタログで探せますが、掲載されていることは品質の保証ではありません。導入前に、更新が続いているか、自分のKubernetesのバージョンに対応しているか、バックアップと復元の手順が文書化されているかを確認します。各プロジェクトの開発状況は変わるため、ここに挙げた名前も執筆時点（2026年10月現在）のものとして、リポジトリで最新の状況を確認してください。

導入するときの注意

権限が広い：Operatorは多くのリソースを作るため、クラスター全体に強い権限を求めることがあります。どのRBACの権限を求めているかを確認し、可能なら監視する名前空間を絞ります。
Operator自体の更新：Operatorにも版があり、CRDのスキーマ変更を伴う更新もあります。クラスターのアップグレードと同じく、検証環境で先に試します。
Operatorが止まったとき：Operatorのコントローラーが止まっても、すでに動いているデータベースのPodはそのまま動き続けます。ただし、その間の障害の切り替えやバックアップは行われません。Operatorのコントローラー自体も監視の対象にします。

自分で作るときの入口

社内の運用手順を自動化したい場合は、Go言語のフレームワークであるKubebuilder（またはそれを土台にしたOperator SDK）を使うと、CRDの定義、コントローラーの雛形、RBACの設定をまとめて生成できます。

kubebuilder init --domain example.com --repo example.com/blog-operator
kubebuilder create api --group apps --version v1alpha1 --kind Blog
make manifests   # 型定義からCRDのYAMLを生成
make install     # CRDをクラスターに登録
make run         # コントローラーを手元で起動して試す

生成されたコントローラーの Reconcile 関数に、先ほどの調整ループを書きます。骨組みは次のような形です。

func (r *BlogReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
	var blog appsv1alpha1.Blog
	if err := r.Get(ctx, req.NamespacedName, &blog); err != nil {
		// 削除済みなら何もしない
		return ctrl.Result{}, client.IgnoreNotFound(err)
	}

	// ここで blog.Spec をもとに Deployment などを「無ければ作る・あれば更新する」
	// 作ったリソースには controllerutil.SetControllerReference で持ち主を記録する

	// 最後に blog.Status を更新する
	return ctrl.Result{}, nil
}

Pythonで書きたい場合はkopf、Javaなら Java Operator SDK といった選択肢もあります。どの道具でも、調整を冪等にする、状態を status に書く、外部の後片付けにはファイナライザーを使う、という原則は共通です。

作り始める前に、既存のOperatorやHelmチャートで足りないかを先に確認してください。Operatorは作った後も、Kubernetesの版上げへの追随や不具合の修正を続ける必要があり、維持の負担は小さくありません。

まとめ

Operatorは、CRD（望む状態の定義）とコントローラー（調整ループ）で、運用の手順をクラスターに組み込む設計。
調整は「今の状態」を見て差を埋める処理で、何度実行しても同じ結果になるように書く。
削除はオーナー参照とファイナライザーで後片付けする。Operatorはカスタムリソースを消してから外す。
ステートレスなアプリにはHelmとDeploymentで十分。Operatorの出番はデータベースや証明書のような運用の判断が必要なもの。
既存のOperatorは更新状況・権限・復元手順を確認して選ぶ。自作はKubebuilderなどから始め、維持の負担も見込む。