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


クラスタは Google Kubernetes Engine(GKE)の基盤であり、コンテナ化されたアプリケーションを表す Kubernetes オブジェクトはすべてクラスタ上で実行されます。

GKE では、クラスタは少なくとも 1 つのコントロール プレーンと、ノードと呼ばれる複数のワーカーマシンで構成されます。これらのコントロール プレーンとノードマシンが、Kubernetes クラスタ オーケストレーション システムを実行します。

次の図は、GKE 内のゾーンクラスタのアーキテクチャの概要を示しています。

GKE は、ゾーン コントロール プレーンですべてのプロビジョニング、維持、管理を行いますが、ノードに対してはプロビジョニングのみを行います。

コントロール プレーン

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

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

コントロール プレーンはクラスタの統合エンドポイントです。クラスタの操作は Kubernetes API 呼び出し経由で行います。コントロール プレーンは、Kubernetes API サーバー プロセスを実行して、これらのリクエストを処理します。Kubernetes API 呼び出しは HTTP/gRPC 経由で直接行うことができますが、Kubernetes コマンドライン クライアント(kubectl)からのコマンドや Cloud Console の UI など、間接的な呼び出し方法もあります。

API サーバー プロセスはクラスタのすべての通信のハブとなります。すべての内部的なクラスタ プロセス(クラスタノード、システムとコンポーネント、アプリケーション コントローラなど)は、API サーバーのクライアントとして機能します。API サーバーはクラスタ全体の信頼できる唯一の情報源となります。

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

コントロール プレーンは、クラスタのすべてのノードで実行される処理を決定します。コントロール プレーンは、コンテナ化されたアプリケーションなどのワークロードをスケジューリングし、ワークロードのライフサイクル、スケーリング、アップグレードを管理します。また、コントロール プレーンは、これらのワークロードのネットワーク リソースやストレージ リソースの管理も行います。

コントロール プレーンとノードは Kubernetes API を介して通信を行います。

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

クラスタを作成または更新した場合、コントロール プレーン(およびノード)で実行されている Kubernetes ソフトウェアのコンテナ イメージが pkg.dev Artifact Registry または gcr.io Container Registry から pull されます。こうしたレジストリに影響する障害により、次のような障害が発生する場合があります。

  • 停止中にクラスタの新規作成が失敗する。
  • 停止中にクラスタのアップグレードが失敗する。
  • 停止の原因と期間によっては、ユーザーの介入がなくてもワークロードの中断が発生する。

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

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

ノード

クラスタには、通常 1 つ以上のノードがあります。これは、コンテナ化されたアプリケーションや他のワークロードを実行するワーカーマシンです。個々のマシンは Compute Engine VM インスタンスであり、これらのインスタンスはクラスタ作成時に GKE によって自動的に作成されます。

各ノードの管理はコントロール プレーンから行われ、各ノード自身が報告するステータスの更新をコントロール プレーンで受信します。ノード ライフサイクルの一部を手動制御にできます。または、クラスタのノードの自動修復自動アップグレードを GKE に実施させることもできます。

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

GKE には、ログ収集やクラスタ内ネットワーク接続などの機能を提供するノード単位のエージェントとして実行される特殊なコンテナもいくつかあります。

ノード マシンタイプ

各ノードは標準の Compute Engine マシンタイプです。デフォルトのタイプは e2-medium です。クラスタを作成するときに、デフォルト以外のマシンタイプを選択できます。

ノード OS イメージ

各ノードでは、コンテナの実行に特化された OS イメージが実行されます。クラスタやノードプールで使用する OS イメージは指定できます。

最小 CPU プラットフォーム

クラスタやノードプールを作成する際には、ノード用の基本となる最小 CPU プラットフォームを選択できます。特定の CPU プラットフォームを選択できるということは、高度なまたは計算集約型のワークロードの場合にメリットがあります。詳細については、最小 CPU プラットフォームをご覧ください。

ノード割り当て可能リソース

ノードのいくつかの必須リソースは、そのノードをクラスタの一部として機能させるのに必要な GKE と Kubernetes ノード コンポーネントを実行します。このため、ノードの総リソース数マシンタイプのドキュメントを参照)と、GKE のノードに割り当て可能なリソース数が異なる場合があります。

マシンタイプが大きいほど実行されるコンテナ数(および Pod 数)が多くなる傾向があるため、大規模なマシンほど、GKE が Kubernetes コンポーネント用に予約するリソースの量が増大します。Windows Server ノードについても、一般的な Linux ノードよりも多くのリソースが必要です。ノードには、Windows OS の実行とコンテナで実行できない Windows Server コンポーネントを考慮に入れ、追加のリソースが必要です。

Pod のリソースのリクエストやリソース使用量の制限を行うことができます。Pod のリソースをリクエストする方法やリソースの使用量を制限する方法については、コンテナ リソースの管理をご覧ください。

クラスタで使用可能なノード割り当て可能リソースを検査するには、次のコマンドを実行します。NODE_NAME は、検査するノードの名前に置き換えます。

kubectl describe node NODE_NAME | grep Allocatable -B 7 -A 6

返される出力には、エフェメラル ストレージ、メモリ、CPU の測定値を含む Capacity フィールドと Allocatable フィールドが存在します。

エビクションのしきい値

Pod で使用できるメモリの量を確認するには、エビクションのしきい値も考慮する必要があります。GKE は、kubelet eviction 用のノードごとにさらに 100 MiB のメモリを予約します。

割り当て可能メモリと CPU リソース

割り当て可能リソースは、次のように計算されます。

ALLOCATABLE = CAPACITY - RESERVED - EVICTION-THRESHOLD

メモリリソースについては、GKE が次のように予約します。

  • メモリが 1 GiB 未満のマシンの 255 MiB のメモリ
  • 最初の 4 GiB のメモリの 25%
  • 次の 4 GiB のメモリの 20%(最大 8 GiB)
  • 次の 8 GiB のメモリの 10%(最大 16 GiB)
  • 次の 112 GiB のメモリの 6%(最大 128 GiB)
  • 128 GiB を超えるメモリの 2%

CPU リソースについては、GKE が次のように予約します。

  • 最初のコアの 6%
  • 次のコアの 1%(最大 2 コア)
  • 次の 2 コアの 0.5%(最大 4 コア)
  • 4 コアを超えるコアの 0.25%

割り当て可能ローカル一時ストレージ リソース

GKE バージョン 1.10 以降では、CPU やメモリリソースと同様にローカル エフェメラル ストレージ リソースも管理できます。Pod でエフェメラル ストレージ リクエストと上限を指定する方法と対処方法については、Kubernetes ドキュメントのローカル エフェメラル ストレージをご覧ください。

通常、GKE は、単一のファイル システムと定期スキャンによってノードを構成します。一時ストレージはローカル SSD でバックアップできます。いずれの場合も、ファイル システムの一部は kubelet 用に予約されています。残りの領域は、割り当て可能ローカル一時ストレージと呼ばれ、一時ストレージ リソースとして使用できます。

kubelet やその他のシステム コンポーネント用に予約されているファイル システムの量は、次のとおりとなります。

EVICTION-THRESHOLD + SYSTEM-RESERVATION

ブートディスクに基づく一時ストレージ

デフォルトでは、一時ストレージはノード ブートディスクによりバックアップされます。この場合、エビクションのしきい値とシステムの予約サイズは、次の式で算出できます。

EVICTION-THRESHOLD = 10% * BOOT-DISK-CAPACITY

SYSTEM-RESERVATION = Min(50% * BOOT-DISK-CAPACITY, 6GB + 35% * BOOT-DISK-CAPACITY, 100 GB)

ブートディスクの容量が増えたときに割り当て可能なエフェメラル ストレージの容量を概算で確認するには、次のグラフをご覧ください。

ブートディスクの容量に応じてエフェメラル ストレージが増加する様子を示すグラフ。関係はほぼ直線を描きます。

ローカル SSD に基づく一時ストレージ

システムの予約領域は、ローカル SSD の数によって異なります。

ローカル SSD の数 SYSTEM-RESERVATION(GB)
1 50
2 75
3 以上 100

エビクションしきい値は、ブートディスクによるエフェメラル ストレージに似ています。

EVICTION-THRESHOLD = 10% * NUM-LOCAL-SSDS * 375 GB

各ローカル SSD の容量は 375 GB です。詳細については、ローカル SSD の追加に関する Compute Engine のドキュメントをご覧ください。