Kubernetes Operatorとは｜CRDの仕組みと自作の判断基準

Kubernetes Operatorとは｜CRDとカスタムコントローラーの関係

結論として、Operatorは単一の製品名ではなく、Kubernetesを拡張して運用を自動化する実装パターンを指します。Kubernetes公式ドキュメントも「カスタムリソースを使用するKubernetesへのソフトウェア拡張」と定義しています（Kubernetes公式：オペレーターパターン）。

実務上は、Operatorは少なくとも次の2つの部品で説明されることが一般的です。

CRDは「独自リソースの型」を定義する

CRD（CustomResourceDefinition）は、クラスターに新しいリソース種別を登録する仕組みです。これを適用すると、kubectlで独自リソースを作れるようになります。

注意したいのは、CRDを入れただけでは何も起こらないという点です。型が増えただけで、そのリソースを見て動く主体がいません。ここを取り違えると「CRDを適用したのに動かない」という詰まり方をします。CRDそのものの位置づけはKubernetes公式のカスタムリソース解説が一次情報になります。

カスタムコントローラーが実際に手を動かす

カスタムコントローラーは、独自リソースを監視して、望ましい状態に近づけるための操作を実行するプログラムです。Podを作る、Secretを更新する、外部APIを叩く。こうした副作用を担当します。

Operator＝CRD＋カスタムコントローラー

この2つをセットで配布したものがOperatorです。利用者が実際に書くCR（カスタムリソース）まで含めると、「CRDで型を定義し、CRを受け取り、コントローラーが処理する仕組み」として整理すると理解がぶれません。標準のDeploymentコントローラーが「レプリカ数を合わせる」ことしか知らないのに対して、Operatorは「このデータベースはフェイルオーバー時にまずレプリカを昇格させ、その後に接続先を切り替える」といったアプリ固有の順序まで知っています。

Operatorが動く仕組み｜調整ループ（Reconcile）

Operatorの中心にあるのは調整ループです。現在の状態を取得し、望ましい状態と比べ、差分を埋める。これを繰り返すだけの単純な構造をしています。

望ましい状態と現在の状態の差分を埋める

利用者が書くのはspec、つまり「こうあってほしい」の宣言です。コントローラーはそれを読み、クラスターの実態を調べ、足りないものを作り、余っているものを消します。処理結果はstatusに書き戻し、利用者が進捗を読めるようにします。

命令的なスクリプトとの違いはここです。スクリプトは「実行した瞬間」だけ正しい。調整ループは、実際の状態がspecからずれたときに、望ましい状態へ繰り返し再収束させます。

冪等性が前提になる

調整ループは何度でも呼ばれます。ノードの再起動でも、無関係なイベントでも呼ばれることがあります。そのため処理は冪等、つまり何回実行しても同じ結果に落ち着くように書く必要があります。

「2回目の実行で重複リソースが増える」実装は、ここを外しているサインです。

削除時の後始末はfinalizerが担う

外部リソース（クラウド上のバケットやDNSレコードなど）を作るOperatorでは、CRが消されたときの後始末が問題になります。Kubernetesはfinalizerという仕組みを用意していて、後始末が終わるまで削除を保留できます。finalizerを付けたまま処理が失敗し続けると、リソースが消せなくなる詰まり方をするため、実装では解除条件を先に決めておきます。

ミニFAQ

Q. Reconcileは何をきっかけに呼ばれますか。

A. 対象のカスタムリソースの作成・更新・削除に加えて、コントローラーが監視対象に指定した関連リソース（Pod、Secret等）の変化でも呼ばれます。定期的な再同期が設定されることも多く、「イベントが来たときだけ」とは限りません。

Q. 調整が失敗し続けるとどうなりますか。

A. 多くのフレームワークでは指数バックオフで再キューされ、間隔を空けながら再試行が続きます。無限に叩き続けるわけではありませんが、失敗理由をstatusのconditionsに出しておかないと、利用者からは「何も起きていない」ようにしか見えません。

CRD設計で最初に決める3点

CRDの設計は、後から変更するコストが高い箇所です。着手前に次の3点を決めておくと、やり直しが減ります。

1. specにどこまで露出させるか

抽象度の決定です。内部実装をそのままspecに並べると、利用者は結局Kubernetesの詳細を理解しなければならず、Operatorを入れた意味が薄れます。逆に絞りすぎると、例外的な要件に応えられず、後から場当たり的なフィールドが増えます。

判断の目安は「利用者が意思決定したい項目だけをspecに出す」です。バージョン、サイズ、バックアップ保持期間あたりは出す。内部のラベル命名規則は出さない。

2. statusとconditionsの持たせ方

statusは利用者への唯一の報告経路です。ここが薄いOperatorは運用時に非常に扱いづらくなります。準備完了かどうか、失敗しているなら何が原因か、最後に成功したのはいつか。この3つは最低限持たせます。

3. バージョニングと移行の方針

CRDにはAPIバージョンがあります。最初はv1alpha1で始めることが多いのですが、実運用に載せた後でフィールド構造を変えたくなった時に、既存のリソースをどう移行するかが問題になります。複数バージョンを併存させる場合はconversion webhookが必要で、これは実装・運用ともに重い部類です。

社内利用の段階で構造を十分に固めておく方が、後の移行コストを抑えやすくなります。

Operatorを自作すべきか｜判断基準と既製Operatorの見極め

ここが本記事の中心です。結論を先に書くと、自作が正当化されるのは「繰り返し」と「分岐」の両方がある場合だけです。

自作しなくていいケース

次に当てはまるなら、Operatorを作る必要はありません。

• インストールして設定を流し込めば終わる。運用中に人間の判断が入らない

• 環境ごとの差分がテンプレートの値の差し替えで表現できる

• 障害時の対応が「Podを再起動する」で済む

この範囲はHelmやKustomizeの担当領域です。デプロイの継続的な適用まで含めたいなら、GitOpsツールを組み合わせる方が保守対象が増えません。ArgoCDとは｜GitOpsの仕組み・Kubernetes運用と案件動向で扱っている構成が、この層でよく採られる選択肢です。

自作を検討していいケース

逆に、次の条件が揃うとOperator化の価値が出ます。

• 同じ運用手順を月に何度も実行していて、手順書がすでに存在する

• その手順に「状態を見て分岐する」判断が含まれる（レプリカの健全性を確認してから昇格する、等）

• 失敗時のリカバリ手順が決まっており、人間がやると事故る

• 複数チームが同じ基盤を使っており、操作を安全に委譲したい

4つ目は見落とされがちですが、実務では効きます。CRDは権限委譲の境界としても機能するためです。利用者にはCRの作成権限だけを渡し、危険な操作はコントローラー側に閉じ込められます。

判断フロー（この記事の整理）

既製Operatorを選ぶときの見極め方

自作の前に、まず既製品を探します。データベース、メッセージキュー、監視系の主要プロダクトは、ベンダーやコミュニティがOperatorを配布していることが多いためです。OperatorHub.ioがカタログとして使えます。

選定時に見る観点は次のとおりです。

• Capability Level：公式の5段階モデル。Level 1は導入と設定、Level 2はアップグレード、Level 3はバックアップ／リストアや複雑な再構成、Level 4はメトリクスとアラート、Level 5は自動スケールや自己修復まで踏み込みます。レベルは累積的で、上位は下位を含みます

• 配布元：プロダクト本家が出しているか、第三者か

• 対応Kubernetesバージョン：どのマイナーバージョンまでを検証・サポート対象として明示しているか

• 直近の更新：新しいマイナーバージョンへの追従が止まっていないか

• 削除時の挙動：finalizerの実装があるか、アンインストール手順が文書化されているか

Level 4以上を求めるのか、Level 1で十分なのか。ここをチームで合意しておくと、「思っていたより何もしてくれない」という導入後のギャップを避けられます。

開発ツールの選び方｜Kubebuilder・Operator SDK・Helm/Ansible

自作すると決めた場合、Goで書くのが最も一般的です。Kubernetes本体とエコシステムがGoで書かれており、型定義やクライアントライブラリをそのまま使えるためです。Go自体の位置づけはGo言語（Golang）とは？ 特徴・用途から年収・将来性まで解説で整理しています。

KubebuilderとOperator SDKの関係

この2つは競合というより階層関係にあります。

Goで書くことが決まっていてエコシステム要件が特にないなら、Kubebuilderから入るのが素直です。Helmチャートをそのまま土台にしたい、あるいはAnsibleの既存Playbookを活かしたいという事情があるなら、Operator SDKの選択肢が効いてきます。

実装前に確認しておくこと

• RBACの設計。コントローラーに何の権限を与えるか。cluster-adminを渡して済ませると、後からスコープを絞れなくなります

• 対象namespaceの範囲。クラスター全体を見るのか、特定namespaceに限定するのか

• webhookを使うか。バリデーションやデフォルト値の注入に便利ですが、証明書管理が必要になります

ミニFAQ

Q. Helmベースで作ったOperatorでも、状態に応じた分岐は書けますか。

A. チャートのテンプレート機能の範囲を超える分岐は苦手です。CRの値を反映してチャートを適用し直す用途には向きますが、「レプリカの健全性を確認してから次の操作に進む」といった手続き的な判断が必要なら、GoやAnsibleベースを検討する方が無理がありません。

自作した後に効いてくる維持コスト

Operatorは作った時点ではなく、作った後にコストが出ます。案件で導入を提案するなら、ここまで含めて話す必要があります。

Kubernetesバージョンへの追従

自作Operatorは、Kubernetes APIに依存したソフトウェアです。本体が更新されれば、依存ライブラリの更新と動作確認が発生します。

Kubernetes本体のパッチリリース方針では、各マイナーバージョンはおよそ14か月メンテナンスされます。うち最初の12か月が標準期間、残り2か月はCVE対応などに限定されたメンテナンスモードです（Kubernetes公式：Patch Releases）。ただしこれは本体プロジェクトの方針であり、実際に使える期間は利用中のディストリビューションやマネージドサービスの提供方針で変わります。そちらも併せて確認したうえで、年1回以上は追従作業の枠を確保しておくのが現実的な計画です。

権限とマルチテナンシー

コントローラーは強い権限を持ちがちです。1つのクラスターを複数チームで使っている場合、Operatorの権限設計がそのままセキュリティ境界になります。namespace単位のスコープに絞れるか、他チームのリソースを誤って操作しない作りになっているか。レビュー時に必ず見られる箇所です。

引き継ぎのしやすさ

フリーランスとして関わる場合、ここが最も重要かもしれません。自作Operatorは「その人しか触れないブラックボックス」になりやすい資産です。CRDのフィールド仕様、statusの読み方、想定する障害シナリオと復旧手順。この3点をドキュメントに残しておかないと、契約終了後に社内で塩漬けになります。

ミニFAQ

Q. Kubernetesのバージョンを上げるとき、自作Operatorで最初に確認すべきことは何ですか。

A. 使用しているAPIグループ・バージョンに非推奨や削除が入っていないかを最初に見ます。次にcontroller-runtimeなど依存ライブラリの対応バージョン、最後にwebhookの証明書まわりです。この順で潰すと手戻りが少なくなります。

ケース別｜フリーランスがOperatorに関わる3パターン

実務での関わり方は、大きく3つに分かれます。

ケース1：内製プラットフォームチームの一員として開発する

事業会社が自社基盤の抽象化を進めている場合、CRDの設計とコントローラー実装を担当します。求められるのはGoの実装力に加えて、利用者である開発チームのニーズを聞いてspecの抽象度を決める力です。役割の全体像はプラットフォームエンジニアとは｜仕事内容・年収・SRE/DevOpsとの違いが近い内容を扱っています。

ケース2：既製Operatorを前提とした運用・保守

実務では、既製Operatorの運用・保守に関わる形で募集要件に含まれるケースが比較的よく見られます。データベースや監視基盤のOperatorが既に入っていて、その運用とトラブル対応を担当する形です。実装より、statusの読み解きとイベントの追跡、アップグレード計画の立案が中心になります。SREとは？仕事内容・年収・必要スキルとDevOpsとの違いをエンジニア視点で解説で整理している業務範囲と重なります。

ケース3：スポットでの設計レビュー

すでに自作Operatorがあり、設計の妥当性を短期で見てほしいという依頼です。CRDのバージョニング方針、RBACのスコープ、finalizerの解除条件。この3点の指摘だけでも価値が出ます。

案件を探すときの視点

Operator関連の募集は「Operator開発」という名前では出てこないことが多く、Kubernetes基盤構築、プラットフォームエンジニアリング、SREといった括りの中に含まれています。案件を確認する際はフリコンの案件一覧でKubernetes関連の募集要件を読み、CRDや内製基盤への言及があるかを見るのが実務的です。

Kubernetes案件そのものの単価レンジはKubernetesとは？仕組み・Dockerとの違い・フリーランス案件の単価をエンジニア視点で解説、SRE／DevOps領域の水準はSREフリーランスの単価相場｜DevOps案件の月額レンジと参入目安で扱っています。自分の経験でどのあたりを狙えるか把握したい場合は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。

よくある失敗と対策

何でもCRDにしてしまう

設定ファイルで済む内容をCRDにすると、APIサーバーへの負荷とスキーマ管理の手間だけが増えます。調整ループが必要かどうかを基準に切り分けます。監視して動く主体がいらないなら、ConfigMapで足ります。

Reconcileに副作用を積み上げる

1回のReconcileで何十もの外部操作を行う実装は、途中で失敗したときの復旧が困難になります。処理を小さく分け、statusで進捗段階を持たせ、次回の呼び出しで続きから再開できる形にします。

statusを書かない

実装者は動いているかどうかをログで判断できますが、利用者にはstatusしか見えません。conditionsに理由まで書いておくと、問い合わせ対応の量が目に見えて減ります。

削除できないリソースを作る

finalizerの解除条件に外部システムの応答を含めると、その外部システムが落ちている間はCRを消せなくなります。タイムアウトと強制解除の手順を最初から用意しておきます。

Operator導入判断チェックリスト

提案や設計レビューの場でそのまま使える形にまとめました。

まとめ

Kubernetes Operatorは、CRDで独自リソースの型を定義し、カスタムコントローラーがその状態を監視して望ましい状態へ収束させる拡張パターンです。自作の是非は「運用の繰り返し」と「状態に応じた分岐」の2軸で判断できます。

• OperatorはCRDとカスタムコントローラーの組み合わせ。CRD単体では何も動かない

• 調整ループは冪等に書く。削除時の後始末はfinalizerで扱う

• CRD設計では、specの抽象度・statusの設計・バージョン移行方針を着手前に決める

• 分岐のない運用ならHelmやGitOpsで足りる。Operator化は保守対象を1つ増やす選択

• 既製Operatorを探すのが先。Capability Levelを共通言語にして期待値を揃える

• Kubernetesのパッチサポートはマイナーバージョンごとにおよそ14か月。追従の枠を年次で確保する

• フリーランスの関わり方は、内製基盤の開発／既製Operatorの運用保守／スポットの設計レビューの3方向

次のステップとしては、既に使っているミドルウェアのOperatorが配布されていないかをOperatorHubで確認し、そのCRDのspecとstatusの設計を読んでみることをおすすめします。他人の設計を読むのが、自作の判断基準を持つ最短ルートです。

参照した一次情報は次のとおりです。

• Kubernetes公式：オペレーターパターン

• Kubernetes公式：カスタムリソース

• Kubernetes公式：Patch Releases（サポート期間）

• Operator SDK：Operator Capability Levels

• Kubebuilder Book

• OperatorHub.io