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

この記事では、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 インターフェースを通じて実装されます。

[[281211]]

リスト監視メカニズム

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 リクエストごとに行われます。

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

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

  1. 型Cacher構造体{
  2. 受信HWMストレージ.HighWaterMark
  3. 受信チャンネルwatchCacheEvent
  4. 同期RWMutex
  5. // キャッシャーのキャッシュにアクセスする前に、準備完了するまで待機します
  6. // これは、ユーザーが構造にアクセスできないようにするために必要です
  7. // 初期化されていないか、現在再入力中です
  8. // 準備完了を設定する必要あります  間違い キャッシャー一時停止または停止したとき
  9. // 準備完了を設定する必要あります  真実 キャッシュ使用可能なったら 
  10. // 初期化。
  11. 準備完了 *準備完了
  12. // 基礎となる storage.Interface。
  13. ストレージ ストレージ.インターフェース
  14. //基礎となるキャッシュ内のオブジェクト予想されるタイプ。
  15. オブジェクトタイプreflect.Type
  16. // "スライディングウィンドウ"  オブジェクト最近の変更現在状態
  17. ウォッチキャッシュ *ウォッチキャッシュ
  18. リフレクタ *cache.Reflector
  19. // Versioner はリソースのバージョンを処理するために使用されます
  20. バージョン管理ストレージ。バージョン管理
  21. // newFunc は Type 型オブジェクトを格納する新しい空のオブジェクトを作成する関数です
  22. newFunc func() ランタイム.オブジェクト
  23. // indexedTriggerは、処理する必要があるウォッチャー数を最適化するために使用されます
  24. // 受信イベント。
  25. IndexedTrigger *indexedTriggerFunc
  26. //ウォッチャー  トリガー 機能する
  27. // ウォッチャーはウォッチャー興味がある
  28. ウォッチャーIDx int  
  29. ウォッチャーインデックスウォッチャー
  30. //待機費やすことができる時間予算を定義します 準備ができていないウォッチャー
  31. // シャットダウンする前にイベントをディスパッチしている間。
  32. dispatchTimeoutBudget *timeBudget
  33. // 正常な終了を処理します。
  34. stopLock sync.RWMutex
  35. 停止したブール
  36. stopCh chan 構造体{}
  37. stopWg sync.WaitGroup
  38. 時計 時計。時計
  39. // タイマーは、基礎となるウォッチャーでの不要な割り当てを回避するために使用されます
  40. タイマー *時間.タイマー
  41. // ディスパッチングは、現在ディスパッチングが行われているどうかを判定します 
  42. //実行中のイベント
  43. ディスパッチブール
  44. // watchersBufferは現在関心がある可能性のあるウォッチャーリストです
  45. // ディスパッチされたイベント。
  46. ウォッチャーバッファ []*cacheWatcher
  47. // blockedWatchers は、現在バッファがいっぱいになっているウォッチャーリストです
  48. ブロックされたウォッチャー []*cacheWatcher
  49. // watchersToStop は停止されるはずだったウォッチャーリストです
  50. //現在のディスパッチ中だが、停止は最後まで延期さ  
  51. //ウォッチャー内のチャネルを閉じることによる競合を回避するために、そのイベントをディスパッチします。
  52. watchersToStop []*cacheWatcher
  53. //ウォッチャーがタイムアウトする前にブックマーク イベントを送信するためのタイムアウト キューを維持します
  54. ブックマークウォッチャー *watcherBookmarkTimeBuckets
  55. // watchBookmark 機能ゲート
  56. watchBookmarkEnabled ブール値
  57. }

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

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

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

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

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

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

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

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

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

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

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

<<:  見落とされがちなマルチクラウドの3つの潜在的な課題

>>:  またまた受賞です! | H3CがGNTCカンファレンスで輝き、インテリジェントネットワークの革新をリード

推薦する

CNCF TOC 委員会メンバー Zhang Lei: 進化するクラウド ネイティブは私たちに何をもたらしたのでしょうか?

[[412417]]クラウドネイティブとは何ですか? 「クラウド ネイティブ」という用語はしばらく前...

Openstack Neutron ネットワーク仮想化

まず、ネットワーク仮想化はなぜ必要なのでしょうか? 1. データセンターの既存のネットワークはクラウ...

vmiss Japanese vpsはどうですか?来月18元で利用できる日本の高帯域幅VPSの簡単なレビュー

vmissはどうですか? vmiss vpsはどうですか? vmiss Japanese vpsはど...

現代の製造業におけるクラウドコンピューティングベースのテクノロジーの重要性

デジタル化はすべての人に影響を及ぼし、企業にとって大きな可能性と課題を生み出します。ほぼすべての業界...

微調整変換を有効活用する

編集者から最適化担当者に異動して以来、前上司の計画に沿ってウェブサイトの最適化を進めてきました。しか...

ファーウェイのホウ・ジンロン氏:フルシナリオインテリジェンスを構築し、世界クラスの「スマート深セン」を創造する

【中国・深セン、2020年7月28日】本日、「スマート深セン、前進」をテーマにしたファーウェイクラウ...

デジタル政府はこれまで以上に重要

紙の文書からデジタルプロセスへの移行は、資源や人件費の削減など、COVID-19パンデミックのような...

外部リンク構築について: 価値ある外部リンクには多額の費用がかかりますか?

ウェブサイトの最適化のタイムウィンドウが2013年に入ると、従来の最適化方法、特に外部リンクの最適化...

早速始めましょう。この記事では、クラウドネイティブ時代のコンテナセキュリティについて理解を深めていきます。

国内需要はセキュリティに配慮するどころか、コンテナ化にはまだまだ遠いと言われている。音は大きいですが...

ソーシャルメディアコンテンツマーケティングにおけるSEO

今日、コンテンツ マーケティングはあらゆる企業のマーケティング戦略の中核となっています。これまでの記...

2018年トップ5プラットフォームの美容コンテンツ開発レポート

コンテンツ市場における重要な垂直カテゴリとして、美容と化粧品は常にユーザーから大きな注目を集めていま...

westhost-仮想ホストを 2 つ購入すると 1 つ無料

Westhost は、仮想ホストの中でも最もリッチで魅力的なホストとされています。MediaTemp...

主流の PC 仮想化: KVM、XEN、OpenVZ の詳細な説明

[[284564]] 1. PC仮想化 - KVM KVM は、Windows/Linux 上でオペ...

外国ドメイン名一覧: 中国のドメイン名の概要

世界にはドメイン名がいくつあるのでしょうか? Xiaoye は正確な数を知りません。しかし、ドメイン...