Nodes

コントロール・プレーン・ノード

Kubernetesコントロール・プレーン・ノードについて説明します。

コントロール・プレーン・ノードは、クラスタ管理、およびKubernetesクラスタ内のリソースの構成および管理に使用されるAPIの公開を担当します。 Kubernetesコントロール・プレーン・ノードのコンポーネントは、専用ポッド内のコンテナのセットとしてKubernetes自体で実行されます。これらのコンポーネントは、コントロール・プレーン・ノードの高可用性(HA)用にレプリケートできます。

コントロール・プレーン・ノードには、次のコンポーネントが必要です。

API Server (kube-apiserver): Kubernetes REST APIは、API Serverによって公開されます。このコンポーネントは、操作の処理と検証を実行し、ワーカー・ノードの操作をトリガーするためにCluster State Storeの情報を更新します。 APIはクラスタへのゲートウェイでもあります。
「クラスタ状態ストア」 (etcd): クラスタ状態に関連する構成データはクラスタ状態ストアに格納され、コントローラ・マネージャやスケジューラなどの調整コンポーネントへの変更をロールアウトできます。クラスタ・ステート・ストアに格納されたデータに対してバックアップ計画を設定することが重要です。
「クラスタ・コントローラ・マネージャ」 (kube-controller-manager): このマネージャは、クラスタ・ステート・ストアおよびAPIサーバーからの入力に基づいて、多くのクラスタ・レベルの機能および全体的なアプリケーション管理を実行するために使用されます。
「スケジューラ」 (kube-scheduler): スケジューラは、リソースの可用性、サービス品質およびアフィニティ仕様をモニタリングすることで、コンテナの実行場所を自動的に決定します。

コントロール・プレーン・ノードは、クラスタ内のワーカー・ノードとして構成できます。したがって、コントロール・プレーン・ノードは標準ノード・サービスも実行: kubeletサービス、コンテナ・ランタイムおよびkube-proxyサービス。ワークロードが不適切なノードで実行されないように、ノードを「染める」できます。 kubeadmユーティリティは、コントロール・プレーン・ノードを自動的に調整して、このノード上で他のワークロードまたはコンテナを実行できないようにします。これにより、コントロール・プレーン・ノードが不要な負荷にならないようにし、コントロール・プレーン・ノードのバックアップおよびリストアを簡略化します。

コントロール・プレーン・ノードが一定期間使用できなくなった場合、クラスタ状態を変更する機能は一時停止されますが、ワーカー・ノードは中断することなくコンテナ・アプリケーションを引き続き実行します。

単一ノード・クラスタの場合、コントロール・プレーン・ノードがオフラインの場合、APIを使用できないため、環境はノードの障害に応答できず、クラスタ全体の状態に影響する新規操作(新規リソースの作成、既存のリソースの編集や移動など)は実行できません。

複数のコントロール・プレーン・ノードを持つHAクラスタは、コントロール・プレーン・ノード機能に対するより多くのリクエストを処理でき、コントロール・プレーン・レプリカ・ノードはクラスタの稼働時間の改善に役立ちます。

コントロール・プレーンのレプリカ・ノード

Kubernetesコントロール・プレーン・レプリカ・ノードについて説明します。

コントロール・プレーンのレプリカ・ノードは、HA用に構成されたKubernetesクラスタ内のコントロール・プレーン・ノードに含まれる機能およびデータを複製します。稼働時間と自己回復性を向上させるために、コントロール・プレーン・レプリカ・ノードを別のゾーンでホストし、Kubernetesクラスタのロード・バランシングを行うように構成できます。

レプリカ・ノードは、コントロール・プレーン・ノード構成と現在のクラスタ状態をリアルタイムでミラー化するように設計されています。コントロール・プレーン・ノードが使用できなくなった場合、Kubernetesクラスタはレプリカ・ノードに自動的にフェイルオーバーできます。コントロール・プレーン・ノードに障害が発生しても、APIは使用可能なままであるため、クラスタは、クラスタ内の既存のリソースを作成および編集するための他のノードの障害やサービス・リクエストに自動的に応答し続けることができます。

ワーカー・ノード

Kubernetesワーカー・ノードについて説明します。

Kubernetesクラスタ内のワーカー・ノードは、コンテナ化されたアプリケーションを実行したり、ネットワークを処理して、クラスタ内外のアプリケーション間でトラフィックをルーティングするために使用されます。ワーカー・ノードは、コントロール・プレーン・ノードで実行されるKubernetes APIによってトリガーされるアクションを実行します。

Kubernetesクラスタ内のすべてのノードで、次のサービスを実行する必要があります。

「Kubeletサービス」 (kubelet): 各ワーカー・ノードと、コントロール・プレーン・ノードで実行されているAPIサーバー間の通信を制御するエージェント。また、このエージェントは、ボリュームのマウント、コンテナの起動、ステータスのレポートなどのポッド・タスクの管理も行います。
Container Runtime: コンテナを実行できる環境。このリリースでは、コンテナ・ランタイムはrunCまたはKata Containersのどちらかです。コンテナ・ランタイムの詳細は、「Kata Containerの作成」を参照してください。
「Kubeプロキシ・サービス」 (kube-proxy): サービス定義をネットワーキング・ルールに変換するサービス。これらのハンドル・ポート転送およびIPリダイレクトにより、ポッド・ネットワークの外部からのネットワーク・トラフィックをサービス内のポッドに透過的にプロキシできます。

いずれの場合も、これらのサービスはデーモンとしてsystemdから実行されます。