【ITニュース解説】Kubernetes: Kubernetes API, API groups, CRDs, and the etcd

Kubernetesは、コンテナ化されたアプリケーションのデプロイ、管理、スケーリングを自動化するためのプラットフォームだ。その中核となるのがKubernetes APIであり、クラスターとのすべてのやり取りはこのAPIを通じて行われる。このAPIは一般的なHTTPS REST APIとして実装されており、Webブラウザやcurlコマンドなど、標準的なHTTPクライアントからアクセスできる。例えば、kubectl proxyコマンドを使えば、ローカル環境からKubernetes APIサーバーへの安全なトンネルを確立し、直接APIエンドポイントにアクセスしてクラスターの情報を取得したり、リソースを操作したりできる。

Kubernetes APIは、クラスター内のあらゆる情報やリソースにアクセスするための入り口となる。例えば、/api/v1というエンドポイントからは、Pod、ConfigMap、ServiceといったKubernetesの基本的なリソースに関する情報を取得できる。また、/apisというエンドポイントからは、それ以外のAPIグループ、例えばアプリケーションを管理するappsグループやバッチ処理を管理するbatchグループなどの情報を得られる。さらに深く掘り下げて/api/v1/podsにアクセスすれば、クラスター内で稼働しているすべてのPodの詳細な情報を確認できる。これにはPodの名前、所属する名前空間、使用しているコンテナイメージ、リソース要求（CPUやメモリ）などが含まれる。

Kubernetesは、クラスター内のリソースを整理するために「APIグループ」「バージョン」「リソースの種類（Kind）」という階層構造を採用している。APIグループは関連するリソースをまとめる役割を担い、各グループは複数のバージョンを持つことができる。そして、バージョンごとに具体的なリソースの種類（Kind）が定義される。例えば、appsというAPIグループには、アプリケーションのデプロイを管理するDeploymentというKindのリソースが存在し、これは通常apps/v1というバージョンで提供される。APIのエンドポイントは、この階層構造に基づいて構築されており、/apis/<group>/<version>/<resource>のような形式で特定のリソースにアクセスできる。ここで、Kindはリソースのスキーマで定義される名前であり、resourceはURIでAPIサーバーに要求する際に使われる名前である。

Kubernetesがこれらすべてのリソース情報やクラスターの状態をどこに保存しているかというと、それが「etcd」という分散型のキーバリューデータベースである。etcdは、Kubernetesクラスターのすべての設定、リソースの状態、認証認可のルールなど、永続化する必要があるデータを一元的に管理する。Kubernetes APIサーバーがリソースの作成や更新のリクエストを受け取ると、まずそのリソースが定義されたスキーマに合致するかどうかを検証し、問題がなければその情報をetcdに保存する。etcdでは、各リソースが特定のキーの下に格納される。例えば、nginx-abcという名前のPodは/registry/pods/default/nginx-abcのようなキーで保存される。データはProtobuf（Protocol Buffers）形式で格納されるため、直接閲覧するには専用のツールが必要になることが多い。

Kubernetesの強力な機能の一つに、このAPIを独自に拡張できる「CustomResourceDefinition（CRD）」がある。CRDは、Kubernetesの既存のリソースでは表現できないような、独自の新しいリソースタイプを定義するための機能だ。CRDを作成することで、既存のKubernetes APIと同じように、独自のAPIグループ、バージョン、そして新しいリソースの種類（Kind）を追加できる。例えば、mycompany.comという独自のAPIグループを作り、その中にMyAppというKindのリソースを定義することができる。CRDの定義には、そのリソースがどのようなフィールドを持ち、それぞれのフィールドがどのような型であるか（例：imageフィールドがstring型であること）をOpenAPIv3スキーマ形式で記述する。

CRDをKubernetesクラスターに適用すると、Kubernetes APIは新しいリソースタイプが追加されたことを認識する。具体的には、既存のapiextensions.k8s.ioというAPIグループを使ってCustomResourceDefinitionオブジェクトを作成することで、myapps.mycompany.comというCRDが登録される。これにより、/apis/mycompany.com/v1/myappsといった新しいAPIエンドポイントが生成され、このエンドポイントを通じてMyAppタイプのリソースを作成、取得、更新、削除できるようになる。この情報はetcdにも保存され、/registry/apiextensions.k8s.io/customresourcedefinitions/myapps.mycompany.comのようなキーでCRD自体の定義が格納される。また、新しいAPIグループへのアクセスを可能にするために、APIServiceリソースも自動的に登録される。これは、新しいAPIグループがどのバージョンをサポートし、どのような優先度を持つかといった情報を含み、APIサーバーのルーティング設定に追加される。

CRDを定義し、それに基づいてカスタムリソースを作成しても、そのリソースが何か具体的なアクションを起こすわけではない。例えば、MyAppというカスタムリソースを作成しても、それに対応するPodが自動的にデプロイされることはない。カスタムリソースは、あくまでその状態をetcdに保存する「データ」に過ぎない。このカスタムリソースの状態を監視し、実際のシステムに変更を適用する役割を担うのが「コントローラー」である。Kubernetes Operatorは、このCRDとコントローラーを組み合わせることで、独自の複雑なアプリケーションのデプロイや管理をKubernetesの仕組みと統合する。

このように、KubernetesはAPIを通じてクラスターのあらゆる要素を管理し、etcdでその状態を永続的に保存している。そして、CRDという仕組みを使うことで、このAPIを自由に拡張し、独自のアプリケーションやインフラストラクチャをKubernetesネイティブな方法で管理できるようになっている。APIサーバーはCRDの作成に応じてAPIServiceを自動的に生成し、新しいAPIエンドポイントをルーティングに追加することで、拡張された機能が既存のKubernetesとシームレスに連携できるようにしている。これにより、開発者はKubernetesの強力な基盤の上に、さらに柔軟でカスタムなソリューションを構築することが可能になるのだ。