Kubernetes 宣言型 API

その中でも、 kubectl は私たちが最もよく使用するコマンドライン ツールです。 K8s は、K8s オブジェクトを管理する kubectl のテクノロジーを次の表に公式にまとめています。

ここで、test という名前の名前空間の下に Deployment オブジェクトを作成して nginx コンテナを実行し、nginx レプリカの数を 5 に変更するとします。3 つの方法は次のとおりです。

1) 命令形コマンドモード

デプロイメント オブジェクトを作成します。

 kubectl デプロイメントの作成 nginx-deployment --image nginx -n test

レプリカの数を変更するには:

 kubectl スケールデプロイメント nginx-deployment --replicas 5 -n テスト

2) 命令型オブジェクト構成法

まず、図 1-1 に示すように、構成ファイルの定義を作成します。

図 1-1 ngin.yaml の構成

デプロイメント オブジェクトを作成します。

 kubectl 作成 -f nginx.yaml

設定ファイル内のレプリカの数を 2 から 5 に変更し、レプリカの数を変更するコマンドを実行します。

 kubectl replace -f nginx.yaml 

3) 宣言的なオブジェクト構成

図 1-1 の構成を使用して、デプロイメント オブジェクトを作成します。

 kubectl を適用-f nginx .yaml

設定ファイル内のレプリカの数を 2 から 5 に変更し、レプリカの数を変更するコマンドを実行します。

 kubectl を適用 -f nginx.yaml 

後者の 2 つのオブジェクト構成方法では、新しいオブジェクトを作成するためのテンプレートが提供され、変更に関連付けられた監査証跡を提供できますが、コマンドではリアルタイム コンテンツに加えてレコード ソースを提供することはできません。そのため、本番プロジェクトの場合、命令型コマンドを直接使用するのではなく、対応する .yaml ファイルを記述して K8s に渡す (宣言型 API の形式で) ことによって、K8s オブジェクトを使用することがよくあります。

設定ファイルは、作成する K8s オブジェクトの情報と、オブジェクトが達成したい望ましい状態を宣言するだけです。これは宣言型の API 対話メソッドです。食事や睡眠などの明示的な指示 (命令型 API とも呼ばれます) とは異なり、構成を使用して作成されたオブジェクトの相互作用は、顧客と実装者の間の通信モードに似ています。これは、顧客は、たとえば「標準的なバスケットボール コートを作ってください」など、目標を達成するために必要な操作について実装者ほど明確ではないことが多いためです。

宣言型 API は、多くの場合、複数の操作をマージする機能を提供します。スタジアムを建設する際には、床を敷くと同時に大型スクリーンを設置することもできます。命令型 API は同時アクセスでは非常に複雑かつ非効率的であり、最終結果の予測可能性を確保するためにロックが必要になることがよくあります。子供は寝ながら食べるのではなく、寝る前に食事を終えなければなりません。また、宣言型 API は現在の状態と最終状態を自然に記録するため、結果を確認しやすくなります。毎日ご飯を3杯食べて、体重を50kgに維持しなければなりません。体重の異なる人がご飯を3杯食べた場合の体重の変化は予測できませんが、カロリー摂取量を調整することで、人によって50kgの目標を達成できます。これが、K8s の宣言型 API が非常に重要である理由です。 K8s 宣言型 API によって記述される主題は、K8s オブジェクトです。冒頭で述べたように、これは K8s を操作するための媒体でありインターフェースです。

では、K8s オブジェクトは K8s API でどのように表現されるのでしょうか? .yaml ファイルを使用してそれらをどのように記述するのでしょうか? .yaml ファイルが K8s に送信されると、どのようにして K8s オブジェクトが作成されますか?

01K8sオブジェクト

K8s オブジェクトは、K8s システム内の永続化されたエンティティを指します。 K8s はこれらのエンティティを使用して、クラスター全体の動作状態を表します。具体的には、以下の情報について説明します。

• どのコンテナ化されたアプリケーションがどのノードで実行されているか
• アプリケーションで使用できるリソース

• 再起動戦略、アップグレード戦略、フォールト トレランス戦略など、実行時のアプリケーションのパフォーマンス戦略。

K8s オブジェクトのすべての操作 (作成、変更、削除) には、K8s API を使用する必要があります。 kubectl コマンドラインを使用する場合でも、プログラム内のクライアントを使用する場合でも、最終的には K8s API が呼び出されます。

各 K8s オブジェクトには、spec と status という 2 つのネストされたオブジェクト フィールドが含まれています。仕様では、有効にされるレプリカの数など、K8s が作成後に達成する必要がある予想される状態について説明します。ステータスはオブジェクトの現在の状態を表します。これは K8s システムとコンポーネントによって監視および設定され、仕様に積極的に一致します。これら 2 つのフィールドは、K8s 宣言型 API を実装する上で最も重要な部分でもあります。

02K8s は API オブジェクトをどのように記述および管理しますか?

Kubernetes オブジェクトを作成するときは、オブジェクトの spec フィールドを指定して、オブジェクトがどのような状態を達成すると予想されるかを K8s に伝える必要があります。また、オブジェクトに関する基本的な情報 (名前など) も提供する必要があります。 kubectl コマンドラインからオブジェクトを作成する場合でも、クライアントから K8s API を呼び出す場合でも、API リクエストにはリクエスト本文に JSON 形式の情報が含まれている必要があります。ほとんどの場合、この情報は .yaml ファイルの形式で提供されます。 kubectl が API リクエストを開始すると、この情報は JSON 形式に変換されます。図 1-1 を例に挙げます。これは、.yaml を使用して K8s オブジェクトを記述するために必要なフィールドとオブジェクトの仕様を示しています。必須フィールドの簡単な説明は次のとおりです。

• apiVersion - オブジェクトの作成に使用された K8s API バージョン
• kind - 作成したいオブジェクトの種類
• メタデータ – 名前文字列、UID、オプションの名前空間など、オブジェクトを一意に識別するのに役立つデータ
• spec – オブジェクトが期待する状態

多くの場合、仕様の正確な形式は、K8s オブジェクトの種類によって異なります。これは管理オブジェクトの詳細な記述の本体であり、K8s によって etcd に永続化されます。仕様が削除されると、オブジェクトもシステムから削除されます。

etcd 内の API オブジェクトの完全なリソース パスは、グループ (API グループ)、バージョン (API バージョン)、リソース (API リソース タイプ) の 3 つの部分で構成されます。具体的なケースを図1-2に示します。

図1-2 K8s API構造

図からわかるように、K8s の API オブジェクトの構成は階層的です。ここでは、これらの API を使用して必要なリソースを取得する方法については詳しく説明しません。興味のある読者は、公式の詳細な説明である次のリンクを参照してください: https://kubernetes.io/zh/docs/reference/using-api/api-concepts/

ここで、CronJob オブジェクトを作成するとします。その yaml ファイルの冒頭は次のようになります。

 APIバージョン: batch/v2alpha1
種類: CronJob
 ...

このうち、batch は API グループ (Group) を表し、v2alpha1 は API バージョン (Version) を表し、CronJob はそれが属する API リソース タイプ (Resource) conjobs の下の特定のカテゴリを表します。全体的な作成プロセスを以下の図 1-3 に示します。

図1-3 永続化プロセス

提出フェーズ

yaml が K8s クラスターに送信されると (プログラム クライアントまたは kubectl 経由)、リクエストは POST に変換され、処理のために K8s API サーバーに渡されます。

フィルタリングと前処理段階

API サーバーは、まずリクエストをフィルタリングして有効な情報を取得し、次に承認、タイムアウト処理、監査などの準備作業を完了します。

ルート検索フェーズ

CronJob の定義を見つけるために、主に MUX と Routes を使用します。具体的なプロセスは、おおよそ次のようになります。1. グループのマッチング。 CronJob などのコア以外の API オブジェクトの場合、K8s は図 1-2 に示すように /apis レベルでそのグループを検索します (Pod や Node などのコア オブジェクトは /api レベルに属し、そのグループは "" です)。 yaml の開始情報に基づいて、/apis/batch を見つけます。 2. バージョン番号を一致させます。次に、バージョン番号 v2alpha1 がパス /apis/batch/ v2alpha1 とさらに照合されます。 K8s では、同じ API オブジェクトに複数のバージョンが存在する場合があります。これは、K8s が共存する複数のバージョンの API を管理するための手段です。 3. リソースタイプを一致させます。最後に、リソース タイプ cronjobs を一致させます。この時点で、K8s は、作成する必要がある特定のリソース タイプが CronJob であることを明確に認識します。

リソースステージの作成

CornJob のタイプ定義を取得した後、API サーバーは変換タスクを実行します。つまり、ユーザーが送信した YAML を、API リソース タイプのすべてのバージョンのフィールドの完全なセットである Super Version オブジェクトに変換します。後でユーザーが他のバージョンの YAML を送信すると、このスーパー バージョン オブジェクトを使用してそれを処理することもできます。次に、Admit 処理が実行されます。これは主に、オブジェクトの作成後にラベルの追加など、いくつかの共通処理ロジックを挿入します。最後に、このオブジェクト内の各フィールドの正当性が検証されます。

保管段階の定義

Validate に合格すると、API サーバーによって Registry と呼ばれる構造に保存されます。有効な K8s API オブジェクトの定義が含まれています。

持続フェーズ

API サーバーは、検証された API オブジェクトをスーパー バージョン バージョンから最初に送信されたバージョンに変換し、シリアル化操作を実行して、最後に etcd API を呼び出して、それらを K8s のエンティティ オブジェクトに変換します。

この時点で、オブジェクトは作成され、永続化されていますが、どのようにして段階的に目的の状態に到達するのでしょうか。 K8s オブジェクトの章で説明されている仕様とステータス情報は、この問題を解決するための基礎となります。 K8s はコントローラー モードを使用してこれを実装します。

03 コントローラーパターンは宣言型APIのsepcを実装する

K8s はコントローラー モードを使用して宣言型 API で記述された仕様状態を実装しますが、コントロール モードの中核となるのは「コントロール ループ」という概念です。 K8s では、コントローラーは、API サーバーを介してクラスターの共有状態を監視し、現在の状態 (ステータス) を目的の状態 (仕様) に移行するための変更を加える制御ループです。

実際のステータスは、リソースのステータス情報を取得するために API を定期的に呼び出したり、ハートビートを通じて kubelet から報告されるコンテナのステータスやノードのステータスなど、K8s 自体のコンポーネントを通じて取得されることが多いです。望ましい状態は、多くの場合、yaml ファイルの spec フィールドによって定義され、永続化のために K8s の etcd に送信されます。図 1-4 は、K8s の制御ループのプロセスを大まかに説明しています。

図1-4 制御ループ

• 仕様とステータスを比較します。同じ場合は、何も操作せずに手順 1 に進みます。それ以外の場合は、差異を出力して手順 2 に進みます。
• コントローラはさまざまなポイントに基づいてシステムに制御操作を発行し、システムは操作を実行してステップ 3 に入ります。
• システムは現在のシステム ステータスをセンサーに報告するか、センサーがアクティブにステータスを取得し、現在のステータスを出力して 1 を返します。

目的は、ステータスを仕様に近づけ、YAML 宣言ステータスの実装を完了することです。図から、センサーとコントローラーがサイクル全体において非常に重要な役割を果たしていることもわかります。

K8s では、センサーは主に Reflector、Informer、Indexer の 3 つのコンポーネントで構成されています。

センサーの全体的なワークフローを図 1-5 に示します。

図1-5 センサーコンポーネント

1. Reflector は、List および Watch 操作を通じて API サーバーから各リソース オブジェクトのステータスを取得します。このうち、List は返される複数のリソースのコレクションを記述するために使用され、主にシステム リソースの完全な更新に使用されます。 Watch は、クライアントが現在のステータスを取得し、その後の変更をサブスクライブするために使用され、主にシステム リソースの増分更新に使用されます。

2. 新しいリソース データを取得した後、 Reflector は Delta レコードを Delta キューにプッシュします。このレコードには、リソース オブジェクト自体の情報とリソース オブジェクト イベントの種類が含まれます。デルタ キューは、キュー内の同じオブジェクトに対してレコードが 1 つだけであることを保証できるため、リフレクターが再リストして監視するときにレコードが重複することを回避できます。

3. Informer コンポーネントは、Delta キューからデルタ レコードを継続的にポップし、リソース オブジェクトをインデクサーに渡します。インデクサーは、デフォルトで名前空間をインデックスとして使用するキャッシュにリソースを記録します。記録操作はスレッドセーフであり、キャッシュはコントローラー マネージャーまたは複数のコントローラー間で共有できます。その後、インフォーマーはイベントをイベント コールバック関数に渡します。

コントローラの主なプロセスを図 1-6 に示します。

図1-6 コントローラコンポーネント

制御ループ内のコントローラー コンポーネントは、主にイベント処理関数とワーカーで構成されます。イベント処理機能は、コントローラーのロジックに基づいて、対応するコールバック処理を実行するかどうかを決定します。イベント処理が必要な場合は、イベント関連リソースの名前空間とリソース名を識別子としてワークキューに挿入し、後続のワーカープールのワーカーが処理します。ワーク キューは、複数のワーカーが同じリソースを処理するのを避けるために、保存されたオブジェクトの重複を排除します。

ワーカーがリソース オブジェクトを処理する場合、通常はリソース名を使用して最新のリソース データを取得する必要があります。このデータが使用される状況は 3 つあります。

• リソースオブジェクトを作成または更新する
• 他の外部サービスを呼び出す、
• ワーカーが処理に失敗した場合は、リソース名を作業キューに再度追加して再試行してください。

ここで、便宜上、図 1-1 で構成されている nginx レプリカを 2 から 3 に拡張する必要があるとします。全体的なプロセスを図 1-7 に示します。

図1-7 レプリカ拡張の全体フローチャート

まず、Reflector は Deployment の変更を監視し、オブジェクト nginx-deployment とタイプが更新されたレコードをデルタ キューに配置します。

一方、Informer は新しい Deployment をキャッシュに更新し、test という名前の名前空間をインデックスとして使用します。一方、Update コールバック関数が呼び出されると、Deployment コントローラは Deployment が変更されたことを検出した後、文字列 test/nginx-deployment を作業キューに挿入します。ワーク キューの背後にあるワーカーは、ワーク キューから文字列 test/nginx-deployment のキーを取得し、キャッシュから最新のデプロイメント データを取得します。

ワーカーは、Deployment 内の spec と status の値を比較して、Deployment を拡張する必要があることを検出し、Ownerreference が nginx-deployment を指す Pod を作成します。

次に、Reflector は新しい Pod イベントを監視し、タイプ Add の追加データ レコードをデルタ キューに追加します。

一方で、Informer は Indexer を介して新しい Pod レコードをキャッシュに保存し、他方では Deployment コントローラーの Add コールバック関数を呼び出します。 Add コールバック関数は、pod3 の ownerReferences をチェックし、対応する Deployment が nginx-deployment であることを確認して、test/nginx-deployment 文字列を作業キューに配置します。

新しい作業項目を受け取った後、Deployment ワーカーはキャッシュから新しい Deployment レコードを取得し、そのすべての Pod 情報を取得します。比較すると、デプロイメント ステータスが最新ではない (関連付けられているポッドの数が変更されている) ことがわかります。この時点で、デプロイメントは仕様とステータスが一致するようにステータスを更新します。

04 結論

• 宣言型 API は初期状態と最終状態を記録するという自然な特性を持っているため、K8s ではこれを API 対話方法の最も重要な部分として採用しています。
• 実稼働環境では、K8s は YAML で記述されたマネージャー API オブジェクトを通じて管理されることが多いです。仕様とステータスは最も重要な情報です。 K8s は、ポジショニングとルーティングを通じて、YAML で記述された情報をエンティティとして etcd に保持します。
• K8s で採用されているコントローラー モードは、宣言型 API によって駆動されます。これは、K8s 宣言型 API を実装するための鍵となります。リソースに対応するコントローラは、制御ループを介してセンサーと結合し、設定された最終状態に向かって制御システムを非同期的に動かします。
• コントローラーは自律的に動作するため、システム全体を自動化し、無人化することが可能になります。

参考文献

[1] https://edu.aliyun.com/lesson_1651_18353?spm=5176.10731542.0.0.5f9e7abdivOOXz#_18353

[2] https://kubernetes.io/zh/docs/concepts/overview/working-with-objects/object-management/

[3] https://kubernetes.io/zh/docs/reference/using-api/api-concepts/#efficient-detection-of-changes

[4] https://kubernetes.io/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/

[5] http://bolismattijssen.github.io/articles/kubernetes-informers-controllers-reflectors-stores

[6] https://ghostwriting.blog.csdn.net/article/details/119155497

[7] https://www.codercto.com/a/65740.html