LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

ステートフルな運用をコード化する必要性

Kubernetes Operatorとは、アプリケーション運用に関する人間の知識をコントローラに実装し、Kubernetes自身にそのアプリケーションの状態管理を自動的に行わせる拡張の仕組みを指します^*1。ステートレスなWebアプリケーションはKubernetes標準のDeploymentやServiceだけで運用しやすい一方、データベースやメッセージキューのようなステートフルなミドルウェアは、バックアップ・障害復旧・バージョンアップグレードといった手順が複雑になりがちです。

Kubernetes公式ドキュメントは、Operatorパターンの狙いを「特定のアプリケーションやサービスを担当する人間のオペレータが持つ、システムがどう振る舞うべきか、どうデプロイするか、問題発生時にどう対応するかという深い知識を捉えること」と説明しています^*1。これまで手作業のRunbook（障害対応手順書）として属人化していた運用ノウハウを、コントローラのコードとして実装し直す取り組みがOperator開発です。

CRDとreconcileループ — Operatorが動く仕組み

カスタムリソース（Custom Resource）とは、Kubernetes APIの拡張機能であり、デフォルトのKubernetesインストールには含まれない、特定用途向けのリソース種別を指します^*2。CustomResourceDefinition（CRD）は、そのカスタムリソースを定義するためのAPIリソースです。CRDオブジェクトを1つ作成すると、指定した名前とスキーマを持つ新しいカスタムリソースがクラスタに追加され^*2、ユーザーはkubectlを使って標準のPodと同じ操作感でこのリソースを作成・参照できます。

Operatorは、このカスタムリソースに対するコントローラとして動作するKubernetes APIのクライアントです^*1。コントローラの中心にあるのが「reconcile（調整）ループ」です。Kubernetes公式ドキュメントは「Operatorの核心は、設定されたリソースに現実を一致させる方法をAPIサーバに伝えるコードである」と説明しています^*1。具体的には、カスタムリソースに書かれた「望ましい状態」と、クラスタ上の「現在の状態」を継続的に比較し、差分があれば是正処理を実行して収束させる、という処理を繰り返します。

この一連の仕組みにより、たとえばデータベースOperatorであれば、PersistentVolumeClaimの作成によるストレージ確保、StatefulSetによるPodの実行、初期設定用Jobの実行、バックアップPodの生成、バージョンアップグレードの実行といった一連の運用作業を自動化できます^*1。これらはいずれも、人間の運用担当者が手順書に沿って行っていた作業に相当します。

Operator SDK・kubebuilder・controller-runtimeの役割分担

Operatorの実装には、ゼロからKubernetes APIクライアントを書く方法もありますが、実務では専用のフレームワークを使うのが一般的です。代表的なものがOperator FrameworkとKubebuilderです。

Operator Frameworkは、Kubernetesネイティブなアプリケーションを効果的・自動的・スケーラブルに管理するためのオープンソースツールキットであり、Operatorの開発を支援するOperator SDK、インストールとライフサイクル管理を担うOperator Lifecycle Manager（OLM）、コミュニティ製OperatorのカタログであるOperator Hubという3つの要素で構成されます^*3。Operator SDKは高レベルAPIと開発用のスキャフォールディング（雛形生成）を提供し、開発者が低レベルなKubernetes API操作を直接書かずにOperatorを組み立てられるようにします。

Kubebuilderは、CRDを使ってKubernetes APIを構築するためのフレームワークであり、Webアプリケーション開発でいうRuby on RailsやSpring Bootに近い位置づけのツールです^*4。Kubebuilderはcontroller-runtimeおよびcontroller-toolsという低レベルライブラリの上に構築されており^*4、CRDのひな形生成、reconcileループの実装を簡素化するコントローラの生成、ボイラープレートコードの削減を担います。controller-runtimeは、reconcileループの実行基盤（イベント監視・キューイング・リトライ制御など）を提供する共通ライブラリであり、Operator SDKとKubebuilderのいずれも内部でこのcontroller-runtimeを利用する設計になっています^*3　*4。両フレームワークは提供する抽象度や周辺機能（雛形の初期構成、CLIコマンド体系など）に違いがありますが、CRD定義とreconcileロジックの実装という中核構造は共通しています。

Basic InstallからAuto Pilotまでの成熟度モデル

Operatorはひとたび作れば完成、というものではなく、段階的に機能を積み上げる前提で設計します。Operator Frameworkが定義するOperator Capability Modelでは、Operatorの成熟度を5段階に整理しています^*3。

Level Iは「Basic Install」で、自動的なアプリケーションのプロビジョニングと設定管理を実現する段階です。Level IIは「Seamless Upgrades」で、パッチバージョンおよびマイナーバージョンのアップグレードに対応します。Level IIIは「Full Lifecycle」で、アプリケーションのライフサイクル管理に加え、バックアップや障害復旧などストレージのライフサイクル管理まで扱います。Level IVは「Deep Insights」で、メトリクス・アラート・ログ処理・ワークロード分析による可観測性を提供します。Level Vは「Auto Pilot」で、水平・垂直スケーリング、自動設定チューニング、異常検知、スケジューリング調整までを自動化する段階です^*3。

この段階分けが実務上重要なのは、発注や内製の判断がOperatorに求める成熟度によって変わるためです。Basic InstallレベルであればCRDとシンプルなreconcile処理で足りますが、Full Lifecycle以上を求める場合はバックアップ・復旧・アップグレードといった多様な異常系を考慮したロジック設計が必要になり、実装・保守の難易度は段階が上がるほど高くなります。

内製の壁と既製Operator活用という選択肢

Operatorを内製する場合、CRDのスキーマ設計だけでなく、reconcileループの冪等性（同じ処理を繰り返しても結果が変わらない性質）の担保、APIサーバとの通信エラー時のリトライ制御、複数リソースにまたがる状態変更の整合性維持など、通常のアプリケーション開発とは異なる設計判断が求められます。Kubernetes自体のAPI仕様やcontroller-runtimeのバージョンアップに合わせた追随作業も継続的に発生します。

この負担を避ける選択肢として、OperatorHubなどのカタログで公開されている既製Operatorを利用する選択肢があります^*3。データベースやメッセージキューなど広く使われるミドルウェアでは、コミュニティやベンダーが提供するOperatorが公開されているケースがあり、自社で一から実装せずに導入できる場合があります。ただし既製Operatorも、自社の運用要件（バックアップ先の指定・監視基盤との連携・マルチテナント構成など）に完全に合致するとは限らず、要件差分をどう埋めるかの検討は必要です。自社固有の業務ロジックをコントローラに組み込みたい場合は、既製Operatorをベースにカスタマイズするか、スクラッチでの開発を選ぶことになります。

外注時の委託範囲と保守負担の論点

Operator開発を外部パートナーに委託する場合、委託範囲を工程単位で切り分けて検討することが大切です。代表的な切り分け方には、CRDのスキーマ設計のみを委託する範囲、reconcileロジックの実装まで含める範囲、テスト・CI構築や監視連携までを含める範囲、リリース後の保守・機能追加まで継続的に依頼する範囲があります。

ここで見落とされやすいのが保守負担です。Operatorはクラスタ内で継続的に動作し続けるソフトウェアであるため、Kubernetesのマイナーバージョンアップやcontroller-runtimeのアップデートに追随できないと、動作不良やAPI非互換の問題が生じる可能性があります。開発を外注して終わりにするのではなく、リリース後のバージョン追随・障害対応・ログ監視をどちらが担うのかを契約時点で明確にしておく必要があります。内製に必要なスキルとしては、Go言語でのプログラミング経験、Kubernetes APIの仕様理解、controller-runtimeやOperator SDK・Kubebuilderの実装経験が挙げられ、これらを兼ね備えた人材の確保は多くの組織にとって容易ではありません。

委託先を誤ると、reconcileループの実装が不十分で意図しない無限ループや過剰なAPIコールが発生し、クラスタ全体の負荷増大やAPIサーバのスロットリングを招くおそれもあります。設計レビューの体制や、既存のOperator実装実績を発注前に確認することが、こうしたリスクを抑えるうえで重要です。

発注前に準備すべき情報

外注を検討する際は、発注前に自社側で整理しておくべき情報があります。第一に、Operatorで自動化したい運用作業の一覧です。バックアップ取得・障害時の自動復旧・スケールの自動調整など、現状Runbookとして手作業で行っている内容を棚卸しし、どこまでをOperatorに任せたいかを明確にします。

第二に、対象となるミドルウェアやアプリケーションの現行構成です。既存のStatefulSetやConfigMapの構成、バックアップ先ストレージの仕様など、Operatorが操作対象とするリソースの情報を整理しておくと、委託先での要件定義がスムーズになります。第三に、求める成熟度レベルです。前述のCapability Modelを参考に、まずはBasic InstallとFull Lifecycleまでを目標にするのか、Deep InsightsやAuto Pilotまで見据えるのかを整理しておくと、見積もりの前提がぶれません。第四に、リリース後の保守体制です。委託先に継続保守を依頼するのか、実装後に運用ノウハウの引き継ぎを受けて内製化するのかを事前に決めておくことで、契約範囲の認識齟齬を防げます。

まとめ：Operator開発を進める3つの判断軸

本稿では、Kubernetes Operatorの仕組みと外注時の論点を整理しました。要点を3つに集約すると次の通りです。第一に、OperatorはCRDで定義したカスタムリソースとreconcileループの組み合わせにより、人間の運用知識をコード化して自動運用を実現する仕組みです。第二に、Operatorの機能はBasic InstallからAuto Pilotまで段階的に成熟させるものであり、内製・既製活用・外注のいずれを選ぶかはこの段階に応じて検討する必要があります。第三に、外注する場合は委託範囲の切り分けとリリース後の保守体制を契約時点で明確にすることが、継続的に動作し続けるOperatorの安定運用につながります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Kubernetes公式ドキュメント「Operator pattern」（https://kubernetes.io/docs/concepts/extend-kubernetes/operator/）
2. *2　出典：Kubernetes公式ドキュメント「Custom Resources」（https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/）
3. *3　出典：Operator Framework公式サイト（https://operatorframework.io/）および「Operator Capability Levels」（https://operatorframework.io/operator-capabilities/）
4. *4　出典：Kubebuilder公式Book（https://book.kubebuilder.io/）およびKubebuilder GitHubリポジトリ（https://github.com/kubernetes-sigs/kubebuilder）

Tweet