【ITニュース解説】A Quick Dive into Kubernetes Operators - Part 2

Kubernetes Operatorは、Kubernetesの機能を拡張し、複雑なアプリケーションのデプロイ、管理、運用を自動化するための強力な仕組みである。この解説では、Operatorの中心となる「コントローラー」の実装と、リソースの検証・変更を行う「Webhook」の利用方法について、具体的なコードと手順を追いながら初心者にもわかりやすく説明する。

まず、Operatorの核となる「コントローラー」の役割を理解する。コントローラーは、Kubernetesクラスター内のリソースの状態を監視し、「望ましい状態」と「現在の状態」の間に差異がある場合に、その差分を埋めるための処理を実行する。この処理は「調停（Reconcile）」と呼ばれ、継続的に行われる。Kubebuilderというツールを使うと、このコントローラーのひな形を簡単に生成できる。このひな形となるinternal/controller/task_controller.goファイルに、Operatorの主要なビジネスロジックを実装する。

このファイルの中心にあるのがTaskReconcilerという構造体で、client.Clientを通じてKubernetes APIとやり取りし、リソースの取得、作成、更新、削除を行う。また、+kubebuilder:rbacという特殊なコメントは、このコントローラーがTaskリソースの読み取り・書き込みや、Kubernetesクラスター内にイベントを作成する権限を持っていることをKubernetesに伝える役割を持つ。

Reconcile関数は、コントローラーの主要な調停ループである。この関数は、Taskリソースが作成、更新、削除されるたびに呼び出される。Reconcile関数の中では、まず処理対象のTaskオブジェクトを取得する。もしオブジェクトが見つからない場合は、すでに削除されたと判断して何もしない。それ以外のエラーが発生した場合は、再試行するためにエラーを返す。

次に、このコントローラーの例では、Taskの状態変化に応じてKubernetesの「イベント」を作成している。イベントは、クラスター内で発生した出来事（リソースの作成、更新、エラーなど）を記録するための標準的な方法であり、管理者がクラスターの状態を把握するのに役立つ。 コードでは、switch文を使ってTaskのライフサイクルに応じたイベントを生成する。

• task.Generation == 1の場合、Taskが新しく作成されたことを示すTaskCreatedイベントを作成する。
• task.DeletionTimestamp.IsZero()の場合、Taskが削除されておらず、通常更新されたことを示すTaskUpdatedイベントを作成する。
• controllerutil.ContainsFinalizerは、finalizerという仕組みがTaskリソースに設定されているかを確認する。finalizerは、リソースが完全に削除される前に、特定のクリーンアップ処理を確実に行うための仕組みである。finalizerが存在し、かつ削除タイムスタンプが設定されている（つまり削除要求があった）場合は、TaskDeletedというイベントを作成し、finalizerを削除する。finalizerを削除することで、KubernetesはTaskリソースの最終的な削除を完了する。

最後にSetupWithManager関数で、このコントローラーがどのリソース（ここではexamplev1.Task）を監視し、どのようにKubernetesマネージャーに組み込まれるかを定義する。

コントローラーのコードを記述した後、実際にクラスターにデプロイする手順は以下の通りだ。まず、make docker-buildコマンドでコントローラーの実行ファイルをOCIイメージ（Dockerイメージのようなもの）にビルドする。次に、kind load docker-imageコマンドを使って、このイメージをKubernetesクラスター（ここではkindというローカルクラスター）にロードする。そして、make deployコマンドでコントローラーをKubernetesクラスターにデプロイし、古いコントローラーポッドを削除して新しいイメージが適用されるようにする。 デプロイ後、kubectl applyでTaskカスタムリソースを作成し、kubectl patchで更新、kubectl deleteで削除する。これらの操作の後、kubectl get eventsコマンドを実行すると、コントローラーが生成したTaskCreated、TaskUpdated、TaskDeletedといったイベントが確認でき、コントローラーが期待通りに動作していることを検証できる。これで、Operatorの基本的な「調停」ロジックが完成した。

次に、より高度なリソース管理機能として「Webhook」の利用について説明する。Kubernetes APIには基本的な検証機能が備わっているが、アプリケーションに固有の複雑なビジネスロジックや制約を課すには不十分な場合が多い。そこでWebhookの出番となる。Webhookは、Kubernetes APIサーバーがリソースを受け入れる前（または削除する前）に、そのリソースを検証したり、自動的に変更したりするための強力なメカニズムである。

Webhookには主に二つの種類がある。

1. バリデーションWebhook: リソースがKubernetes APIサーバーに永続化される前に、その内容が特定のルールに従っているかを検証する。例えば、Taskのpriorityが1から5の範囲内であるか、deadlineが未来の日付であるかといったカスタムルールを適用できる。Kubebuilderのcreate webhookコマンドで、バリデーションWebhookのひな形を生成できる。internal/webhook/v1/task_webhook.goファイルには、ValidateCreate、ValidateUpdate、ValidateDeleteという関数が生成され、それぞれリソースの作成、更新、削除時に呼び出されるバリデーションロジックを記述できる。
2. ミューテーションWebhook: リソースがAPIサーバーに永続化される前に、そのリソースの内容を自動的に変更またはデフォルト値を注入する。これは、ユーザーが指定しなかったフィールドにデフォルト値を設定したり、特定のラベルを自動的に追加したりするのに便利である。同じくinternal/webhook/v1/task_webhook.goファイルに生成されるDefault関数で、ミューテーションロジックを実装する。

この例のミューテーションWebhookでは、Taskリソースが作成される際に、task.Labelsにpriorityとdeadlineの値を自動的に追加し、finalizerも自動的に付与している。これにより、ユーザーはこれらのフィールドを手動で指定することなく、Taskリソースを簡潔に作成できるようになる。

Webhookをデプロイするには、証明書の管理が必要となる。cert-managerは、Webhookが安全に動作するために必要な証明書を自動的に管理・発行するツールであり、これをまずKubernetesクラスターにデプロイする。その後、config/crd/kustomization.yamlとconfig/default/kustomization.yamlファイル内のWebhook関連の設定を有効にするためのコメントを解除する。これはKubernetesの設定ファイルをカスタマイズするKustomizeという仕組みで、Webhookの設定をクラスターに適用するために必要な手順である。 これらの設定変更後、コントローラーのデプロイ時と同様に、make docker-build、kind load docker-image、make deploy、kubectl delete podのコマンドでアプリケーションを再デプロイする。

再デプロイが完了したら、kubectl applyでmetadataフィールドを省略したTaskリソースを作成してみる。その後、kubectl get tasks task-sample-3 -o yamlコマンドで作成されたTaskの詳細を取得すると、ミューテーションWebhookによってlabels（example.example.com/priorityやexample.example.com/deadline）とfinalizersが自動的に追加されていることが確認できる。これはミューテーションWebhookが正しく機能し、リソースの自動変更が行われたことを示している。

まとめると、コントローラーはKubernetesリソースの「望ましい状態」への調停というコアなビジネスロジックを担う。一方、WebhookはKubernetes APIサーバーに到達するリソースに対して、検証ルールを強制したり、デフォルト値を自動的に注入したりする「アドミッションコントロール」の役割を果たす。このコントローラーとWebhookの組み合わせこそが、単なるリソースマネージャーではなく、堅牢で自己管理型のアプリケーションを構築するためのOperatorの真髄となる。これらの基本的な知識と実践を通じて、より複雑なOperator開発の土台を築くことができる。