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

Autopilot Standard

---

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

このページは、IT ソリューションとシステム アーキテクチャを定義する管理者、アーキテクト、オペレーターを対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。

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 オブジェクトについて
• 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 ステータス ダッシュボードを開きます。

ベスト プラクティス:

リージョン停止中にアプリケーションを利用できるようにするため、複数のリージョンを横断してデプロイします。

注意: Container Registry は非推奨となりました。今後、提供終了となります。2024 年 1 月 8 日より前に Container Registry を使用していない組織では、デフォルトで Artifact Registry に新しい gcr.io リポジトリがホストされます。2024 年 5 月 15 日以降、それまで Container Registry を使用していなかった Google Cloud プロジェクトでは、Artifact Registry で gcr.io ドメインのイメージのホスティングと管理のみがサポートされます。

Container Registry は 2025 年 3 月 18 日に提供終了となる予定です。サポート終了の詳細については、Container Registry のサポート終了をご覧ください。

ノードについて

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

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

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

ベスト プラクティス:

stdout を使用するとプラットフォームでアプリケーション ログを処理できるため、コンテナ化されたアプリケーションには stdout を使用します。

ノード管理は、クラスタの運用モードによって次のように異なります。

ノード コンポーネント	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 のマシンタイプを選択して構成します。必要に応じて、サイズ設定、スケーリング、数量、スケジュール、場所を構成できます。