Kubernetes API を拡張するにはどうすればいいですか?

Django は汎用 Web フレームワークですが、Kubernetes はコンテナオーケストレーターです。当然ですが、異なるプロジェクトをまったく比較すべきではありません。ただし、この一連の記事では、Kubernetes の謎を解き明かし、その API はごく普通の HTTP API であり、かなり馴染みのある方法で拡張できることを示したいと思います。

kubectl プラグインの作成からスケジューラ拡張機能の実装まで、カスタム機能を使用して Kubernetes を拡張する方法は多数あります。拡張ポイントの詳細なリストは公式ドキュメントに記載されていますが、このアプローチに基づいてランキング付けが行われた場合、カスタムコントローラーまたはオペレーターの開発が勝利すると思います。

Kubernetes コントローラーの背後にある考え方はシンプルですが強力です。システムの理想的な状態を記述し、それを Kubernetes に永続化してから、コントローラーがジョブを実行してクラスターの実際の状態を理想的な状態に十分近づける (または障害を報告する) のを待ちます。

ただし、コントローラーはメディアで多くの注目を集めていますが、私の意見では、カスタムコントローラーの作成は、Kubernetes API を拡張するというより広範なタスクの一部 (おそらくオプション) と見なすのがほとんどです。しかし、これに気づくには、典型的なワークフローに多少精通している必要があります。

カスタムコントローラ

Kubernetes コミュニティは、より広範で一般的なコントローラーの定義を提供していますが、私は 1 年以上 Kubernetes コントローラーに取り組んできた結果、これまでに見たカスタムコントローラーのほとんどをカバーする次の説明を思いつきました。

コントローラーは、実際には、目的の状態を読み取り、それに応じて実際の状態を更新するアクティブな調整プロセス (つまり、無限ループ) です。
ただし、コントローラーは通常、単一の Kubernetes リソースタイプにバインドされます。これをコントローラーのメインリソースと呼びます。
コントローラーはシステムイベントをリッスンします。最も重要なのは、プライマリリソースオブジェクトの作成または変更ですが、その他の (セカンダリまたは所有) リソースの変更、タイマーイベントなどもリッスンします。
イベントの性質に関係なく、イベントを 1 つ以上のプライマリリソースタイプのオブジェクトに関連付けることは常に可能です。

イベントが発生すると、コントローラーは API から対応するプライマリリソースオブジェクトを 1 つずつ読み取り、各オブジェクトの標準プロパティ (つまり、目的の状態) をチェックし、システムを目的の状態に近づけるための変更を適用し、この状態を使用して各オブジェクトを順番に更新します。

コントローラーは、ポッド、ジョブ、サービスなどの組み込みリソースを含む、任意のリソースタイプをプライマリリソースとして持つことができます。問題は、すべてではないにしても、ほとんどの組み込みリソースに、対応する組み込みコントローラーが既に存在することです。したがって、複数のコントローラーが共有オブジェクトの状態を更新することを避けるために、カスタムリソース用にカスタムコントローラーが記述されることがよくあります。

本質的に、リソースとは何でしょうか? Kubernetes 自身の言葉:

リソースは、特定のタイプの API オブジェクトのコレクションを格納する Kubernetes API のエンドポイントです。たとえば、組み込みの Pods リソースには、Pod オブジェクトのコレクションが含まれています。

したがって、リソースが単なる Kubernetes API エンドポイントである場合、リソースのコントローラーを記述することは、リクエストハンドラーを API エンドポイントにバインドするための単なる巧妙な方法になります。

プライマリリソースエンドポイントへの作成または変更要求があるたびに、コントローラーのロジック (特に) がトリガーされます。要求パラメータ (オブジェクトの仕様フィールド) と応答ステータス (オブジェクトのステータスフィールド) のデータ転送オブジェクトとして制御ループの反復をトリガーするメインリソースタイプのインスタンス。

コントローラーベースのハンドラーと従来のリクエストハンドラーの主な違いは、処理が実際の API リクエストとは非同期に行われるという点です。 Kubernetes オブジェクトを作成または変更する API リクエスト (POST、PUT、PATCH など) は、単にコントローラーの作業をディスパッチするだけです (インテントを記録することによって)。一方、オブジェクトを取得する API リクエスト (GET、WATCH) は、処理ステータスを返すために使用されます。

カスタムリソース

Kubernetes API へのリクエストハンドラーの追加がコントローラーの記述によって行われる場合、新しい API エンドポイントをどのように追加しますか?

この質問に答える前に、Kubernetes API には 2 種類のエンドポイントがあることを理解することが重要です。

最初のタイプは、Pod、ConfigMap、サービスなどの Kubernetes オブジェクト (つまり、永続的な Kubernetes エンティティ) のコレクションを提供するエンドポイントです。API エンドポイントの大部分はこのタイプです。
2番目は基本的にその他すべてです。 /metrics、/logs、/apis などのエンドポイントは、他の種類のエンドポイントの最も顕著な例です。これらのエンドポイントは、Kubernetes API サーバーに埋め込まれるか、API 集約レイヤーを使用して実装されます。

コントローラーは通常、最初のタイプのエンドポイントを使用します。では、ユーザー定義のオブジェクトタイプを提供する新しいエンドポイントを API に追加するにはどうすればよいでしょうか?

まず、CustomResourceDefinition (CRD) を記述する必要があります。 CRD 自体は、新しいカスタムリソースを記述するオブジェクトです。最も重要なのは、CRD に新しいリソースタイプの名前とバージョン管理されたオブジェクトスキーマ (つまり、フィールド) が含まれている必要があることです。
次に、CRD をクラスターに送信する必要があります。 CRD をクラスターに適用すると、カスタムリソースタイプを提供する新しい Kubernetes API エンドポイントが作成されます。とても簡単です！

カスタムリソースタイプのオブジェクトは、組み込みの Kubernetes オブジェクトとよく似た外観と動作をします。一般的な API 機能 (CRUD、フィールド検証、検出など) のメリットを享受できると同時に、カスタムユースケースを解決するために必要なプロパティも備えています。

カスタムリソースは、それ自体でも役立ちます。新しいリソースを登録すると、(ある程度の制限付きで) 永続性、すぐに使用できるフィールド検証、RBAC などがすぐに利用できるようになります。ただし、ほとんどの場合、カスタムリソースはカスタムコントローラーとともに作成されます。

ウェブフック

リクエスト処理に戻ります...

Kubernetes コントローラーの優れた点は非同期性ですが、これが最大の制限でもあります。オブジェクトを作成、変更、または削除するための Kubernetes API へのリクエストは記録されたインテントとして機能し、実際の処理ロジックは次の制御ループの反復まで延期されます。しかし、同期リクエスト処理が必要な場合はどうなるでしょうか?

Kubernetesでも可能です!ただし、これを行うには、Kubernetes API サーバーのリソース要求処理に介入する必要があります。

リクエストが API サーバーに到達すると、変更が etcd (または同様のもの) に保持される前にいくつかの段階を経ます。

認証と承認
入場管理
オブジェクトスキーマ検証
ライセンスの確認

上記のステージのほとんど (またはすべて?) は、カスタムロジックを使用して拡張できます。

したがって、アドミッション Webhook を構成すると、Kubernetes API サーバーはリソースインスタンス (AdmissionReview というエンベロープでラップされている) を実際に永続化する前にカスタム HTTPS エンドポイントに送信するようになります。

承認 Webhook エンドポイントを呼び出すと、Kubernetes API サーバーによるリクエスト処理がブロックされます。 Admission Webhook 実装では、任意の検証ロジックを実行したり、オブジェクトの属性に重要なデフォルト値を設定したり、オブジェクトにラベルを付けたり注釈を付けたり、さらには他の Kubernetes リソースを変更したり、外部システムに変更を加えたりすることもできます。

一般に、Webhook ハンドラーの副作用は避ける必要があります。 Webhook では、オブジェクトが実際に保存されるか、処理チェーンによって拒否されるかを知ることは不可能です。リソースに対する操作がこれらのチェックのいずれかによって拒否された場合、前の手順で行われた変更を何らかの方法で元に戻す必要があります。

したがって、Webhook は同期リクエストハンドラーを Kubernetes API エンドポイントにバインドする簡単な方法です。これにより、Kubernetes API と他の従来の HTTP API との機能の同一性が完成します。