GKE クラスタのアーキテクチャ


このページでは、Google Kubernetes Engine(GKE)クラスタのアーキテクチャについて説明します。コンテナ化された Kubernetes ワークロードはすべて GKE クラスタで実行されます。

GKE クラスタは、コントロール プレーンとノードと呼ばれるワーカーマシンで構成されます。コントロール プレーンとノードが、Kubernetes クラスタのオーケストレーション システムを構成します。GKE Autopilot は、コントロール プレーン、ノード、システム コンポーネントなど、クラスタの基盤となるインフラストラクチャ全体を管理します。 GKE Standard モードの場合、GKE がコントロール プレーンとシステム コンポーネントを管理し、ユーザーがノードを管理します。 次の図は、GKE クラスタのアーキテクチャを示しています。

GKE クラスタのアーキテクチャコントロール プレーンは GKE によって管理され、API サーバー、リソース コントローラ、スケジューラ、クラスタ ストレージを実行します。Autopilot モードの場合、ノードは GKE で管理され、Standard モードの場合はユーザーが管理します。ユーザー Pod がノード内でコンテナを実行します。他の Google Cloud サービスを GKE と統合することもできます。

コントロール プレーンについて

コントロール プレーンは、Kubernetes API サーバー、スケジューラ、コアリソース コントローラなどのプロセスを実行します。GKE は、クラスタの作成から削除までのコントロール プレーンのライフサイクルを管理します。コントロール プレーン上で実行される Kubernetes バージョンのアップグレードも管理の対象になります。アップグレードは GKE によって自動的に行われますが、自動スケジュールの前に手動で行うこともできます。

コントロール プレーンと Kubernetes API

コントロール プレーンはクラスタの統合エンドポイントです。コントロール プレーンは Kubernetes API 呼び出しを介して操作します。コントロール プレーンは、Kubernetes API サーバー プロセス(kube-apiserver)を実行して API リクエストを処理します。Kubernetes API 呼び出しは次の方法で行います。

  • 直接呼び出し: HTTP/gRPC
  • 間接呼び出し: kubectl などの Kubernetes コマンドライン クライアント、または Google Cloud コンソール

API サーバー プロセスはクラスタのすべての通信のハブとなります。すべての内部クラスタ コンポーネント(ノード、システム プロセス、アプリ コントローラなど)は、API サーバーのクライアントとして機能します。

API リクエストにより、クラスタ内のオブジェクトに対して「望ましい状態」が Kubernetes に通知されます。Kubernetes は常にその状態を維持しようとします。Kubernetes では、API のオブジェクトを命令で構成することも、宣言で構成することもできます。

Kubernetes でのオブジェクト管理の詳細については、以下のページをご覧ください。

コントロール プレーンとノードのインタラクション

コントロール プレーンは、クラスタのすべてのノードで実行される処理を管理します。コントロール プレーンは、ワークロードをスケジューリングし、ワークロードのライフサイクル、スケーリング、アップグレードを管理します。また、これらのワークロードのネットワーク リソースやストレージ リソースの管理も行います。コントロール プレーンとノードは Kubernetes API を使用して相互に通信を行います。

コントロール プレーンと Artifact Registry のインタラクション

クラスタを作成または更新すると、GKE はコントロール プレーンとノードで実行されている Kubernetes システム ソフトウェアのコンテナ イメージを pkg.dev Artifact Registry または gcr.io Container Registry から pull します。これらのレジストリに影響する停止が発生すると、次の処理が失敗する可能性があります。

  • 新しいクラスタの作成
  • クラスタのバージョンのアップグレード

停止の原因と期間によっては、ユーザーの介入がなくてもワークロードの中断が発生する場合があります。

pkg.dev Artifact Registry または gcr.io Container Registry が特定のリージョンで停止した場合、停止の影響を受けないゾーンまたはリージョンにリクエストがリダイレクトされることがあります。

Google Cloud サービスのステータスを確認するには、Google Cloud ステータス ダッシュボードを開きます。

ノードについて

ノードは、コンテナ化されたアプリケーションと他のワークロードを実行するワーカーマシンです。個々のマシンは、GKE によって作成される Compute Engine 仮想マシン(VM)です。コントロール プレーンは、各ノードから報告されるノードのステータスを管理します。

ノードは、クラスタのワークロードを構成するコンテナをサポートするために必要なサービスを実行します。これにはランタイムと Kubernetes ノード エージェント(kubelet)も含まれます。後者は、コントロール プレーンと通信し、ノード上でスケジュールされたコンテナの起動と実行を行います。

また、GKE では、ノードごとのエージェント(DaemonSet)として稼働する多くのシステム コンテナが実行され、ログの収集やクラスタ内のネットワーク接続などの機能を提供しています。

ノード管理は、次のようにクラスタの運用モードによって異なります。
ノード コンポーネント Autopilot モード Standard モード
ライフサイクル

GKE によるフルマネージド。例:

GKE は次の処理を管理します。

ユーザーは次の処理を管理できます。

可視性 kubectl を使用してノードを表示します。gcloud CLI や Google Cloud コンソールには、基盤となる Compute Engine 仮想マシンは表示されません。また、アクセスもできません。 kubectl、gcloud CLI、Google Cloud コンソールを使用してノードを表示します。基盤となる Compute Engine VM が表示され、アクセスできます。
接続性 基盤となる VM に直接接続しません。 SSH 経由で基盤となる VM に接続します。
ノードのオペレーティング システム(OS) GKE が管理します。すべてのノードで containerd を含む Container-Optimized OS(cos_containerdが使用されます。 ノードのオペレーティング システムを選択します
マシン ハードウェアの選択

ユースケースに基づいて、Pod で compute クラスをリクエストします。

GKE がマシンの構成、スケジュール、数量、ライフサイクルを管理します。

ノードプールの作成時に、Compute Engine のマシンタイプを選択して構成します。必要に応じて、サイズ設定、スケーリング、数量、スケジュール、場所を構成できます。