【ITニュース解説】Kubernetes: what are the Kubernetes Operator and CustomResourceDefinition

Kubernetesは、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するための強力なプラットフォームである。その機能を最大限に活用し、さらに拡張するために「Kubernetes Operator」と「CustomResourceDefinition (CRD)」という概念が用いられる。これらは、標準のKubernetesリソースでは表現できないような、複雑なアプリケーションのライフサイクル管理や外部システムとの連携を可能にする重要な仕組みである。

まず、Kubernetesの基本的な自動化の仕組みとして「Controller（コントローラ）」の概念を理解する必要がある。コントローラは、Kubernetesクラスタ内のリソースの状態を監視し、その現在の状態を、あらかじめ定義された「望ましい状態」に一致させるためのサービスである。例えば、ReplicaSetコントローラは、指定された数のPodが常に稼働しているかを確認し、不足していればPodを作成し、多すぎれば削除することで望ましい状態を維持する。デプロイメントコントローラはReplicaSetの作成や更新を制御し、PersistentVolumeコントローラはディスクリソースの管理を行う。コントローラは「コントロールループ」と呼ばれる巡回プロセスで動作し、常にリソースをチェックし、現在の状態と望ましい状態に差異があれば、その差異を解消するためのアクションを実行する。これらのコアコントローラはKubernetesに組み込まれており、kube-controller-managerというコンポーネントの一部として機能している。また、これら既存のコントローラに加えて、ユーザーが独自の「カスタムコントローラ」を作成することも可能である。

次に、「Kubernetes Operator（オペレータ）」とは何かを説明する。オペレータは、簡単に言えば「強化されたカスタムコントローラ」と表現できる。オペレータもKubernetesクラスタ内でPodとして動作する独自のサービスであり、Kubernetes APIを通じてリソース情報の取得や更新を行う。しかし、通常のコントローラがPod、Node、Serviceなどの標準的なKubernetesリソースを扱うのに対し、オペレータは「カスタムリソース（CR）」と呼ばれる独自のリソースタイプを扱う点が最大の特徴である。このカスタムリソースの定義は「CustomResourceDefinition (CRD)」によって行われる。つまり、オペレータは一つ以上のカスタムコントローラと、それに対応するCRDの組み合わせである。通常のコントローラが既存のリソースの変化に対応するのに対し、オペレータは新しい種類のリソースをKubernetesに導入し、そのリソースの管理を専門に行うコントローラを提供する。

「CustomResourceDefinition (CRD)」は、KubernetesのAPIを拡張し、ユーザーが独自のカスタムリソースを定義するための「設計図」である。CRDをKubernetesに適用することで、新しいAPIグループとバージョンを持つカスタムリソースタイプがKubernetes APIに追加され、あたかも標準リソースであるかのようにkubectlコマンドで操作できるようになる。CRDの定義には、リソースのグループ名、バージョン、単数形・複数形名、スコープ（クラスタ全体か名前空間内か）、そして最も重要な「スキーマ」が含まれる。スキーマは、カスタムリソースが持つべきフィールドとそのデータ型を記述するものであり、OpenAPI v3スキーマ形式で定義される。例えば、ニュース記事の例では、MyAppというカスタムリソースを定義し、そのリソースがimage（Dockerイメージ）とbanner（表示テキスト）というフィールドを持つことをCRDで記述している。このCRDをクラスタに適用すると、demo.rtfm.co.ua/v1という新しいAPIグループにmyappsというリソースタイプが追加され、kubectl get myappのようなコマンドでカスタムリソースのインスタンスを操作できるようになる。

CRDがカスタムリソースの定義を提供し、オペレータがそのカスタムリソースの管理を行う。ニュース記事の例では、myapp-crd.yamlでMyAppというカスタムリソースを定義し、その後にmyapp-example-resource.yamlで具体的なMyAppリソース（example-appという名前）を作成している。この時点ではPodはまだ作成されない。なぜなら、そのMyAppリソースを監視し、それに基づいてPodを作成する「コントローラ」（この場合はオペレータ）が存在しないからである。

ここで、KopfというPythonフレームワークを使ったオペレータの実装例が登場する。このオペレータは、CRDで定義されたMyAppカスタムリソースの作成イベントを監視する。MyAppリソースが作成されると、オペレータはカスタムリソースのspecフィールドからimage（例：nginx:latest）とbanner（例：This pod was created by MyApp operator 🚀）の値を抽出し、これらを使用してKubernetes Podの定義を作成する。オペレータは、あらかじめ用意されたPodテンプレート（pod.yaml）をこれらの値で埋め込み、Kubernetes APIを通じて新しいPodをクラスタに作成する。このようにして、MyAppカスタムリソースを作成するだけで、そのリソースの指定に従ったPodが自動的に起動する仕組みが実現される。このPodのログには、カスタムリソースのbannerフィールドで指定されたテキストが表示される。KopfやKubebuilder（Go言語向け）のようなフレームワークは、このようなオペレータの開発を効率化するためのツールである。これらのフレームワークを使用しない場合でも、Go言語のk8s.io/apiやk8s.io/client-goライブラリを使ってKubernetes APIと直接対話することで、同様の機能を持つオペレータを実装できる。

オペレータの力は、Kubernetes内部のリソース管理にとどまらない。より高度なオペレータは、AWSのロードバランサーやデータベースサービスなど、Kubernetes外部のクラウドサービスのリソースを管理することも可能である。例えば、ニュース記事にあるAWS ALB (Application Load Balancer) を管理するオペレータの例では、MyIngressというカスタムリソースを作成し、そのspecフィールドにサブネットやスキーマなどの情報を記述する。オペレータは、このMyIngressリソースを監視し、AWS SDK（Pythonのboto3やGoのaws-sdk-go）を使ってAWS APIにリクエストを送信し、ALBを自動的にプロビジョニングする。ALBのDNS名やARNなどの情報は、カスタムリソースのstatusフィールドに書き込まれ、ユーザーはkubectl get myingress -o yamlコマンドなどでその状態を確認できるようになる。

このように、Kubernetes OperatorとCustomResourceDefinitionは、Kubernetesの強力な拡張メカニズムである。CRDによって新しいリソースタイプを定義し、オペレータがそのカスタムリソースのライフサイクルを自動で管理することで、Kubernetesは単なるコンテナオーケストレーションツールを超え、あらゆる複雑なアプリケーションや外部サービスの自動運用プラットフォームへと進化する。これは、データベースや監視システムなど、標準的なKubernetesリソースでは管理しきれない複雑なステートフルアプリケーションのデプロイと運用を自動化する上で極めて有効なアプローチである。