このページでは、コンテナ化されたワークロードを実行する Google Kubernetes Engine（GKE）クラスタのアーキテクチャについて説明します。このページでは、コントロール プレーン、ノード、さまざまな GKE クラスタ コンポーネントが相互にどのようにやり取りするかについて説明します。
このページは、IT ソリューションとシステム アーキテクチャを定義する管理者、アーキテクト、オペレーターを対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。
このページを読む前に、Kubernetes クラスタ アーキテクチャを理解しておいてください。
GKE クラスタは、コントロール プレーンとノードと呼ばれるワーカーマシンで構成されます。コントロール プレーンとノードが、Kubernetes クラスタのオーケストレーション システムを構成します。GKE Autopilot は、コントロール プレーン、ノード、システム コンポーネントなど、クラスタの基盤となるインフラストラクチャ全体を管理します。 GKE Standard モードの場合、GKE がコントロール プレーンとシステム コンポーネントを管理し、ユーザーがノードを管理します。
次の図は、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）として稼働する多くのシステム コンテナが実行され、ログの収集やクラスタ内のネットワーク接続などの機能を提供しています。
stdout を使用するとプラットフォームでアプリケーション ログを処理できるため、コンテナ化されたアプリケーションには stdout を使用します。
| ノード コンポーネント | Autopilot モード | 標準モード |
|---|---|---|
| Lifecycle | 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 のマシンタイプを選択して構成します。必要に応じて、サイズ設定、スケーリング、数量、スケジュール、場所を構成できます。 |