この記事では、Kubernetesのさまざまなコンポーネント間の通信メカニズムについて説明します。

Kubernetes についてある程度理解できたので、この記事では引き続きシステム レベルで Kubernetes について説明し、Kubernetes の基本コンポーネントと、これらのコンポーネントがどのように連携して複雑なクラスター システムをサポートするかを見ていきます。以下の記事を読んで、Kubernetes の素晴らしい設計を理解しましょう。

[[281210]]

Kubernetesの基本コンポーネント

Kubernetes は、次の図に示すように、クラスター全体を制御ノードとワーカーノードに分割します。

Kubernetes のマスターは、クラスター制御ノードを指します。各 Kubernetes クラスターには、クラスター全体の管理と制御を担当するマスター ノードが必要です。 Kubernetes 内のすべての制御命令はマスターによって処理されます。クラスター内で非常に重要な役割を果たすため、デプロイメント時には複数のノードを個別にデプロイする必要があります。

マスターノードのキープロセス

Apiserver: すべての Kubernetes リソースを追加、削除、変更、およびチェックするための唯一のエントリ ポイントを提供し、クラスター制御のエントリ ポイントでもあります。クラスター管理、リソース クォータ、アクセス制御、認証と承認、etcd での操作を完了するための http Rest インターフェイスを提供します。

コントローラー マネージャー: クラスター内のすべてのリソース オブジェクトの自動制御センターであり、ポッドとノード、ノード コントローラー、サービス コントローラー、レプリカ コントローラー、サービス アカウント、トークン コントローラーなどの管理を担当します。

スケジューラ: リソースのスケジュール設定、Apiserver の監視、スケジュールされていないポッドがあるかどうかの確認を担当します。

Etcd: Kubernetes システムには、ストレージに etcd を使用する必要がある 2 つの主要なサービスがあります。

ネットワークプラグイン: ネットワーク構成情報を保存する必要があるフランネルなど

Kubernetes 自体、さまざまなオブジェクトのステータスとメタデータ構成を含みます。

マスター ノードを除き、クラスター内の他のノードはノード ノードと呼ばれ、以前のバージョンではミニオンとも呼ばれていました。ノードは、クラスター内の特定のワークロード ノードであり、物理マシンまたは仮想マシンになります。

ノードキープロセス（以下のプロセスを含むが、これらに限定されない）

Kubelet: マスターからこのノードに送信されたタスクを処理し、ポッドとそのコンテナを管理します。各 kubelet は Apiserver に独自の情報を登録し、ノードのリソース使用状況をマスターに定期的に報告し、cAdvisor を通じてコン​​テナとノードの情報を監視します。

kube-proxy: サービスへのアクセスをバックエンドの複数のポッドインスタンスに転送し、ルーティング情報を維持します。 TCP タイプの k8s サービスごとに、kube-proxy はバランシング アルゴリズムを担当するローカル ソケット サーバーを確立し、rr ロード バランシング アルゴリズムを使用します。

CNI ネットワーク コンポーネント: コンテナ プラットフォームの標準化されたネットワーク コンポーネントとして、コンテナのセグメント間通信サポートを提供し、Kubernetes クラスターのオーバーレイ ネットワークを実装するための鍵となります。

Docker: Kubernetes はさまざまなコンテナ ツールをサポートしています。現在、Docker は主流のコンテナであり、Kubernetes クラスターのコンテナの作成と管理を提供します。

クラスターコンポーネント間の相互作用

Kubernetes は、すべてのリソースを追加、削除、変更、およびチェックするための唯一のエントリ ポイントです。各コンポーネントは、リスト監視モードで Apiserve にリクエストを送信します。 Apiserver への負荷を軽減するために、各コンポーネントはキャッシュを使用してデータをキャッシュします。場合によっては、機能モジュールは Apiserver に直接アクセスせず、キャッシュにアクセスすることで間接的に Apiserver にアクセスします。

Kubelet と API サーバー

各ノード上の kubelet は、Apiserver の REST インターフェースを呼び出して、一定期間ごとに自身のステータスを報告します。 Kubelet は、ウォッチ インターフェースを通じてポッド情報を監視します。作成、削除、変更イベントをリッスンします。

コントローラーマネージャー&APIサーバー

コントローラー マネージャーには複数のコントローラーが含まれています。たとえば、Node Controller モジュールは Node 情報を監視し、API サーバーが提供する Watch インターフェイスを通じて対応するアクションを実行します。

スケジューラと API サーバー

スケジューラは、API サーバーの監視インターフェースを通じてリッスンします。新しく作成されたポッドのコピーをリッスンした後、ポッドの要件を満たすすべてのノードのリストを取得し、ポッドのスケジューリングの実行を開始します。スケジューリングが成功すると、ポッドは特定のノードにバインドされます。

以下は、典型的なポッド作成のフローチャートです。Apiserver が中心になっていることがわかります。クラスター内の各機能モジュールの元のデータはすべて、etcd を操作するために kube-apiserver を通じて削除、変更、チェックされます。このデータを取得して操作する必要がある場合は、Apiserver の REST インターフェースを通じて実装されます。

リスト監視メカニズム

Kubernetes は、その設計概念がエッジ トリガーではなくレベル トリガーを使用するため、他の分散システムのように MQ を導入しません。コンポーネント間のメッセージ通知を解決するために、リストウォッチャー メカニズムを実装するために http+protobuffer のみを使用します。したがって、コンポーネント間の通信を理解する前に、まず Kubernetes でのリスト監視メカニズムの適用を理解する必要があります。

List-watch は、k8s の統合された非同期メッセージ処理メカニズムです。 List は、HTTP 短縮リンクに基づいて実装されたリソースのリスト API を呼び出してリソースをリストします。 watch は、リソースのウォッチ API を呼び出して、HTTP ロングリンクに基づいて実装されるリソース変更イベントをリッスンします。 Kubernetes では、各コンポーネントは Apiserver のリソースの変更を監視してリソースのステータスを更新します。

ここでは時計の簡単な説明を示します。プロセスは次の図に示されています。

フローチャートのこの部分は複雑に見えませんが、実際の実装は非常に独創的です。この写真に基づいた簡単な説明:

1 まず、list または watch のデータはすべて etcd データから取得されることを強調しておく必要があります。そのため、Apiserver では、すべてが最新の etcd データを取得してクライアントに返すように設計されています。

2 Apiserver は各コンポーネントから送信された監視要求をリッスンする場合、リスト要求と監視要求の形式が類似しているため、最初に ListResource 関数を入力して分析します。ウォッチ要求として解析された場合、要求に応答するためのウォッチャー構造が作成されます。ウォッチャーのライフ サイクルは、各 HTTP リクエストごとに行われます。

 //各ウォッチリクエストはウォッチャー構造に対応します
func (a *APIInstaller) registerResourceHandlers(path string, storage rest.Storage,... ...
 …
リストア、isLister := storage.(rest.Lister)
ウォッチャー、isWatcher := storage.(rest.Watcher) ...(1) ...の場合  "LIST" : //特定の種類のリソースをすべて一覧表示します。
 …

3 ウォッチャーは作成されますが、etcd データを受信して​​キャッシュするのは誰でしょうか? Apiserver は cacher を使用して etcd イベントを受信します。 Cacher もストレージ タイプです。ここで、cacher は etcd を監視するインスタンスとして理解できます。 Cacher は特定の種類のデータを対象とします。そのキャッシャーは、ListAndWatch() メソッドを通じて etcd に監視要求を送信します。 etcd は特定のタイプのデータを watchCache 構造に同期します。つまり、ListAndWatch() はリモート データ ソースを cacher 構造に継続的に同期します。 Cacher の構造は次のとおりです。

型Cacher構造体{
 受信HWMストレージ.HighWaterMark
 受信チャンネルwatchCacheEvent
 同期RWMutex
 // キャッシャーのキャッシュにアクセスする前に、準備が完了するまで待機します。
 // これは、ユーザーが構造にアクセスできないようにするために必要です。
 // 初期化されていないか、現在再入力中です。
 // 準備完了を設定する必要があります に 間違い キャッシャーが一時停止または停止したとき。
 // 準備完了を設定する必要があります に 真実 キャッシュが使用可能になったら 
 // 初期化。
 準備完了 *準備完了
 // 基礎となる storage.Interface。
 ストレージ ストレージ.インターフェース
 //基礎となるキャッシュ内のオブジェクトの予想されるタイプ。
 オブジェクトタイプreflect.Type
 // "スライディングウィンドウ"  オブジェクトの最近の変更と現在の状態。
 ウォッチキャッシュ *ウォッチキャッシュ
 リフレクタ *cache.Reflector
 // Versioner はリソースのバージョンを処理するために使用されます。
 バージョン管理ストレージ。バージョン管理
 // newFunc は、 Type 型のオブジェクトを格納する新しい空のオブジェクトを作成する関数です。
 newFunc func() ランタイム.オブジェクト
 // indexedTriggerは、処理する必要があるウォッチャーの数を最適化するために使用されます。
 // 受信イベント。
 IndexedTrigger *indexedTriggerFunc
 //ウォッチャーは、​  トリガー 機能する
 // ウォッチャーはウォッチャーに興味がある
 ウォッチャーIDx int  
 ウォッチャーインデックスウォッチャー
 //待機に費やすことができる時間予算を定義します 準備ができていないウォッチャー
 // シャットダウンする前にイベントをディスパッチしている間。
 dispatchTimeoutBudget *timeBudget
 // 正常な終了を処理します。
 stopLock sync.RWMutex
 停止したブール
 stopCh chan 構造体{}
 stopWg sync.WaitGroup
 時計 時計。時計
 // タイマーは、基礎となるウォッチャーでの不要な割り当てを回避するために使用されます。
 タイマー *時間.タイマー
 // ディスパッチングは、現在ディスパッチングが行われているかどうかを判定します 
 //実行中のイベント。
 ディスパッチブール
 // watchersBufferは現在関心がある可能性のあるウォッチャーのリストです
 // ディスパッチされたイベント。
 ウォッチャーバッファ []*cacheWatcher
 // blockedWatchers は、現在バッファがいっぱいになっているウォッチャーのリストです。
 ブロックされたウォッチャー []*cacheWatcher
 // watchersToStop は停止されるはずだったウォッチャーのリストです
 //現在のディスパッチ中だが、停止は最後まで延期された の 
 //ウォッチャー内のチャネルを閉じることによる競合を回避するために、そのイベントをディスパッチします。
 watchersToStop []*cacheWatcher
 //ウォッチャーがタイムアウトする前にブックマーク イベントを送信するためのタイムアウト キューを維持します。
 ブックマークウォッチャー *watcherBookmarkTimeBuckets
 // watchBookmark 機能ゲート
 watchBookmarkEnabled ブール値
}

watchCache の構造は次のとおりです。

 watchCache構造体型{
 sync.RWMutex //同期ロック
 cond *sync.Cond //条件変数
 capacity int // 履歴スライディングウィンドウ容量
 keyFunc func(runtime.Object) (string, error) //ストレージからキー値を取得する
 getAttrsFunc func(runtime.Object) ( labels.Set , fields.Set , bool , error) //オブジェクトのフィールドとラベル情報を取得します
 cache []watchCacheElement //循環キューキャッシュ
 startIndex int //循環キューの開始インデックス
 endIndex int //循環キューの終了インデックス
 ストアcache.Store //
 リソースバージョン uint64
 onReplace関数()
 onEvent func(*watchCacheEvent) //この関数は、キャッシュ内のデータが追加/更新/削除されるたびに呼び出され、オブジェクトの以前のバージョンの値を取得します。
 時計 時計。時計
 バージョン管理ストレージ。バージョン管理
}

キャッシュはすべての操作イベントを保存し、ストアは最新のイベントを保存します。

4 cacheWatcher は、watchCache から特定の resourceVersion、つまり initEvents 以降のすべてのデータを取得し、そのデータを入力チャネルに格納し、フィルターに渡して結果チャネルに出力し、特定のクライアントにデータを返します。

型cacheWatcher構造体{
 sync.Mutex // 同期ロック
 input chan *watchCacheEvent //入力パイプライン、Apiserverはイベントが発生したときにブロードキャスト形式で入力パイプラインに送信します
 result chan watch.Event//出力パイプライン、更新パイプラインに出力
 完了 chan 構造体{}
 フィルター filterWithAttrsFunc // フィルター
 停止したブール
 関数を忘れる(bool)
 バージョン管理ストレージ。バージョン管理
}

ポッド作成プロセスから k8s コンポーネントの通信を観察する

上記の Pod 作成フローチャートに戻りましょう。図から次の情報を確認できます。

1 まず、各コンポーネントは初期化中に Apiserver に監視要求を送信します。これは図の 0 でマークされた命令です。 ApiserverはkubeApiserverを作成し、各APIルーティング情報を登録すると、Watchリクエストのルーティング情報を取得します。

2 Kubectl がポッドを作成するリクエストを Apiserver に送信した瞬間から、各作成および更新操作は etcd に保存されます。

3 各コンポーネントは Apiserver に監視リクエストを送信し、Apiserver は etcd から最新のデータを取得して返します。

注: イベントが発生すると、Apiserver はそれをこれらのウォッチャーのチャネルにプッシュします。各ウォッチャーには独自のフィルターがあります。監視するイベントが見つかると、パイプラインを通じて対応するコンポーネントにデータを送信します。