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 との機能の同一性が完成します。

要約する

すべてを 1 枚の写真に収めてみましょう。 Kubernetes API 拡張ワークフローの説明は次のとおりです。

ここまでで、カスタム コントローラーは Kubernetes API を拡張するという大きなタスクの一部にすぎないことがおわかりいただけたと思います。

上記の説明をすべて読んだ後、Kubernetes が私たちがよく知っている従来のテクノロジーと何ら変わらないことにも気付いていただければ幸いです。

• Kubernetes カスタム リソースは、API に新しい HTTP エンドポイントを追加する簡単な方法です。
• Kubernetes カスタム コントローラーは、非同期ハンドラーを API エンドポイントにバインドする方法です。
• Kubernetes Admission Webhook は、同期ハンドラーを同じ API エンドポイントにバインドする方法です。

つまり、Kubernetes と Django はそれほど違いはありません。

真面目な話、よく知っている類推を使うと、新しい概念をより早く理解できることが多いです。しかし、理解するだけでは不十分で、流暢な表現が必要な場合は、練習することで概念を実際の概念として内面化できることがよくあります。ただし、それは別の記事で取り上げるトピックです。乞うご期待！