初心者が知っておくべきKubernetesアーキテクチャ

コントロールプレーンコンポーネント

ETCD

etcd は、Kubernetes オブジェクト データ (ポッド、レプリケーション コントローラー、シークレット、サービスなど) の永続ストレージのバッキング ストアとして使用される、高速で分散された一貫性のあるキー値ストアです。実際、etcd は Kubernetes がクラスターの状態とメタデータを保存する唯一の場所です。 etcd と直接通信する唯一のコンポーネントは Kubernetes API サーバーです。他のすべてのコンポーネントは、API サーバーを介して間接的に etcd にデータを読み書きします。

Etcd は、キーの変更を非同期的に監視するためのイベントベースのインターフェースを提供する監視機能も実装しています。キーが変更されると、そのオブザーバーに通知されます。 API サーバー コンポーネントは、通知を受け取り、etcd の現在の状態を目的の状態に移行するためにこれに大きく依存しています。

etcd インスタンスの数は奇数にする必要がありますか?

HA 環境では通常、3、5、または 7 個の etcd インスタンスを実行しますが、それはなぜでしょうか? etcd は分散データ ストアであるため、水平方向に拡張できますが、各インスタンスのデータが一貫していることを確認する必要があり、そのためにはシステムが状態について合意に達する必要があります。 Etcd はこれに RAFT コンセンサス アルゴリズムを使用します。

このアルゴリズムでは、次の状態に進むためにクラスターの過半数 (またはクォーラム) が必要です。 etcd インスタンスが 2 つしかない場合、いずれか 1 つに障害が発生すると、多数派が存在しないため etcd クラスターは新しい状態に移行できません。一方、インスタンスが 3 つある場合は、1 つのインスタンスに障害が発生しても、多数派に達したインスタンスは引き続き使用できます。

API サーバー

API サーバーは、Kubernetes 内で etcd と直接やり取りする唯一のコンポーネントです。 Kubernetes とクライアント (kubectl) 内の他のすべてのコンポーネントは、クラスターの状態を処理するために API サーバーを経由する必要があります。 API サーバーは次の機能を提供します。

• etcd にオブジェクトを保存するための一貫した方法を提供します。
• これらのオブジェクトの検証は、クライアントが etcd データストアに直接書き込む場合に発生する可能性のある、誤って構成されたオブジェクトを保存できないように実行されます。
• リソースを作成、更新、変更、または削除するための RESTful API を提供します。
• 楽観的同時実行ロックを提供するため、同時更新の場合、オブジェクトへの変更が他のクライアントによって上書きされることはありません。
• クライアントから送信されたリクエストに対して認証と承認を実行します。プラグインを使用して、クライアントのユーザー名、ユーザー ID、およびユーザーが所属するグループを抽出し、認証されたユーザーが要求されたリソースに対して要求されたアクションを実行できるかどうかを判断します。
• リクエストがリソースの作成、変更、または削除を試行すると、アドミッション コントロールが実行されます。例: AlwaysPullImagesDefaultStorageClass、ResourceQuota など。
• クライアントが変更を監視するための監視メカニズム (etcd に類似) を実装します。これにより、スケジューラやコントローラ マネージャなどのコンポーネントが API サーバーと疎結合方式で対話できるようになります。

コントローラーマネージャー

Kubernetes では、コントローラーはクラスターの状態を監視し、必要に応じて変更を加えたり要求したりする制御ループです。各コントローラーは、現在のクラスターの状態を目的の状態に近づけようとします。コントローラーは少なくとも 1 つの Kubernetes リソース タイプを追跡し、これらのオブジェクトには目的の状態を表す正規フィールドがあります。

コントローラーの例:

• レプリケーション マネージャー (ReplicationController リソースのコントローラー)
• レプリカセット、デーモンセット、ジョブコントローラ
• デプロイメント コントローラー
• ステートフルセットコントローラー
• ノードコントローラ
• サービス コントローラー
• エンドポイント コントローラ
• 名前空間コントローラ
• 永続ボリューム コントローラー

コントローラーは監視メカニズムを使用して変更の通知を受け取ります。これらは、API サーバーを監視してリソースの変更を検出し、新しいオブジェクトの作成、既存のオブジェクトの更新や削除など、変更ごとにアクションを実行します。ほとんどの場合、これらの操作には他のリソースの作成や監視対象のリソース自体の更新が含まれますが、監視を使用してもコントローラーがイベントを見逃さないことが保証されるわけではないため、何も見逃されていないことを確認するために定期的に再リスト操作も実行されます。

コントローラー マネージャーは、名前空間の作成とライフサイクル、イベント ガベージ コレクション、終了したポッド ガベージ コレクション、カスケード削除ガベージ コレクション、ノード ガベージ コレクションなどのライフサイクル機能も実行します。

スケジューラ

スケジューラは、ポッドをノードに割り当てるコントロール プレーン プロセスです。割り当てられたノードを持たない新しく作成されたポッドを監視し、スケジューラが検出した各ポッドに対して、そのポッドを実行するのに最適なノードを見つける責任をスケジューラが負います。

Pod のスケジューリング要件を満たすノードは、実行可能ノードと呼ばれます。適切なノードがない場合、ポッドはスケジューラが配置できるようになるまでスケジュールされないままになります。実行可能なノードが見つかると、一連の関数を実行してノードにスコアを付け、スコアが最も高いノードを選択します。次に、選択されたノードについて API サーバーに通知します。このプロセスはバインディングと呼ばれます。

ノードの選択は 2 つのステップに分かれています。

• すべてのノードのリストをフィルタリングして、ポッドをスケジュールできる許容可能なノードのリストを取得します。 (たとえば、PodFitsResources フィルターは、候補ノードに Pod の特定のリソース要求を満たすのに十分なリソースがあるかどうかを確認します)
• ステップ 1 で取得したノードのリストにスコアを付け、ランク付けして最適なノードを選択します。複数のノードのスコアが最高値の場合、ラウンドロビンを使用して、ポッドがすべてのノードに均等にデプロイされるようにします。

スケジュールの決定において考慮する必要がある要素は次のとおりです。

• Pod はどのようなハードウェア/ソフトウェア リソースを要求しますか?ノードはメモリまたはディスクの負荷を報告しますか?
• ノードには、ポッド仕様のノードセレクターと一致するラベルがありますか?
• ポッドが特定のホスト ポートへのバインドを要求した場合、そのポートはノード上ですでに使用されていますか?
• ポッドはノード汚染を許容しますか?
• ポッドはノードアフィニティルールまたは反アフィニティルールを指定していますか?待って。

スケジューラは、選択されたノードにポッドを実行するように指示しません。スケジューラが行うことは、API サーバーを通じてポッド定義を更新することだけです。 API サーバーは、ウォッチ メカニズムを通じてポッドがスケジュールされたことを Kubelet に通知します。ターゲット ノード上の kubelet サービスは、ポッドがそのノードにスケジュールされたことを確認し、ポッドのコンテナを作成して実行します。

ワーカーノードのコンポーネント

クベレット

Kubelet は、クラスター内のすべてのノードで実行されるエージェントであり、ワーカーノードで実行されるすべてのものを担当するコンポーネントです。コンテナが Pod 内で実行されることを保証します。

kubelet サービスの主な機能は次のとおりです。

• API サーバーにノード リソースを作成して、実行中のノードを登録します。
• API サーバー上のノードにスケジュールされているポッドを継続的に監視します。
• 構成されたコンテナ ランタイムを使用してポッドのコンテナを起動します。
• 実行中のコンテナを継続的に監視し、そのステータス、イベント、リソース消費量を API サーバーに報告します。
• コンテナの生存プローブを実行し、プローブが失敗した場合はコンテナを再起動し、そのポッドが API サーバーから削除された場合はコンテナを強制終了し、ポッドが終了したことをサーバーに通知します。

kubeプロキシ

これはすべてのノードで実行され、ポッドが別のポッドと通信できること、ノードが別のノードと通信できること、コンテナーが別のコンテナーと通信できることなどを保証します。また、API サーバーを監視してサービスとポッドの定義の変更を検出し、全体的なネットワーク構成を最新の状態に保つ役割を担います。サービスが複数のポッドで構成されている場合、プロキシはこれらのポッド間で負荷分散を行います。

kube-proxy は、接続を受け入れて Pod にプロキシする実際のプロキシ サーバーであるため、その名前が付けられています。現在の実装では、iptables または ipvs ルールを使用して、実際のプロキシ サーバーを経由せずに、ランダムに選択されたバックエンド Pod にパケットをリダイレクトします。

• サービスが作成されると、仮想 IP アドレスがすぐに割り当てられます。
• API サーバーは、ワーカー ノードで実行されている kube-proxy エージェントに、新しいサービスが作成されたことを通知します。
• 各 kube-proxy は、iptables ルールを設定することでサービスをアドレス指定可能にし、各サービス IP/ポート ペアがインターセプトされ、宛先アドレスがサービスをサポートするポッドの 1 つに変更されるようにします。
• API サーバーを監視して、サービスまたはそのエンドポイント オブジェクトの変更を確認します。

コンテナランタイム

コンテナの実行、コンテナの名前空間と cgroup の設定に重点を置いたコンテナ ランタイムは低レベル コンテナ ランタイムと呼ばれ、イメージのフォーマット、解凍、管理、共有、開発者のニーズを満たす API の提供に重点を置いたコンテナ ランタイムは高レベル コンテナ ランタイム (コンテナ エンジン) と呼ばれます。

コンテナ ランタイムは次の処理を担当します。

• ローカルで利用できない場合は、コンテナに必要なコンテナ イメージがイメージ レジストリから取得されます。
• イメージはコピーオンライト ファイル システムに抽出され、すべてのコンテナー レイヤーが重ね合わされて、マージされたファイル システムが作成されます。
• コンテナのマウントポイントを準備します。
• コンテナが期待どおりに実行されるように、CMD の上書き、ユーザー入力からの ENTRYPOINT、SECCOMP ルールの設定など、コンテナ イメージからメタデータを設定します。
• カーネルを変更して、プロセス、ネットワーク、ファイル システムなどのコンテナーに何らかの分離を割り当てます。
• CPU やメモリの制限など、いくつかのリソース制限を割り当てるようにカーネルに通知します。
• コンテナを起動するには、システム コール (syscall) をカーネルに渡します。
• SElinux/AppArmor が正しく設定されていることを確認してください。