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

クラスタは 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 を介して通信を行います。

コントロール プレーンと gcr.io Container Registry とのインタラクション

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

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

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

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

ノード

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

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

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

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 のリソースをリクエストする方法やリソースの使用量を制限する方法については、コンテナ リソースの管理をご覧ください。

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

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

ここで、node-name は検査するノードの名前です。

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

エビクションのしきい値

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

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

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

Allocatable = Capacity - Reserved - Eviction Threshold

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

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

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

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

次の表に、クラスタの Linux ワークロードを標準ノード マシンタイプごとにスケジュールするために使用できる、割り当て可能なメモリと CPU リソースの量を示します。

マシンタイプ メモリ容量(GB) 割り当て可能メモリ(GB) CPU 容量(コア数) 割り当て可能 CPU(コア数)
c2-standard-4 16 13.3 4 3.92
c2-standard-8 32 28.6 8 7.91
c2-standard-16 64 58.7 16 15.89
c2-standard-30 120 111.2 30 29.89
c2-standard-60 240 228.4 60 59.85
e2-micro 1 0.62 2 0.941
e2-small 2 1.35 2 0.941
e2-medium(デフォルト) 4 2.76 2 0.941
e2-standard-2 8 6.1 2 1.93
e2-standard-4 16 13.3 4 3.92
e2-standard-8 32 28.6 8 7.91
e2-standard-16 64 58.7 16 15.89
e2-highmem-2 16 13.3 2 1.93
e2-highmem-4 32 28.6 4 3.92
e2-highmem-8 64 58.7 8 7.91
e2-highmem-16 128 118.6 16 15.89
e2-highcpu-2 2 1.5 2 1.93
e2-highcpu-4 4 2.9 4 3.92
e2-highcpu-8 8 6.1 8 7.91
e2-highcpu-16 16 13.3 16 15.89
g1-small 1.7 1.2 1 0.94
m1-megamem-96 1433.6 1414.7 96 95.69
m1-ultramem-40 961 942.1 40 39.85
m1-ultramem-80 1922 1903.1 80 79.77
m1-ultramem-160 3844 3825.1 160 159.69
m1-ultramem-208 5888 5869.1 208 207.69
m1-ultramem-416 11776 11757.1 416 415.69
n1-standard-1 3.75 2.7 1 0.94
n1-standard-2 7.5 5.7 2 1.93
n1-standard-4 15 12.3 4 3.92
n1-standard-8 30 26.6 8 7.91
n1-standard-16 60 54.7 16 15.89
n1-standard-32 120 111.2 32 31.85
n1-standard-64 240 228.4 64 63.77
n1-standard-96 360 346.4 96 95.69
n1-highmem-2 13 10.7 2 1.93
n1-highmem-4 26 22.8 4 3.92
n1-highmem-8 52 47.2 8 7.91
n1-highmem-16 104 96.0 16 15.89
n1-highmem-32 208 197.4 32 31.85
n1-highmem-64 416 400.8 64 63.77
n1-highmem-96 624 605.1 96 95.69
n1-highcpu-2 1.8 1.3 2 1.93
n1-highcpu-4 3.6 2.6 4 3.92
n1-highcpu-8 7.2 5.5 8 7.91
n1-highcpu-16 14.4 11.9 16 15.89
n1-highcpu-32 28.8 25.3 32 31.85
n1-highcpu-64 57.6 52.5 64 63.77
n1-highcpu-96 86.4 79.6 96 95.69
n2-standard-2 8 6.1 2 1.93
n2-standard-4 16 13.3 4 3.92
n2-standard-8 32 28.6 8 7.91
n2-standard-16 64 58.7 16 15.89
n2-standard-32 128 118.6 32 31.85
n2-standard-48 192 182.6 48 47.85
n2-standard-64 256 244.4 64 63.77
n2-standard-80 320 308.4 80 79.77
n2-highmem-2 16 13.3 2 1.93
n2-highmem-4 32 28.6 4 3.92
n2-highmem-8 64 58.7 8 7.91
n2-highmem-16 128 118.6 16 15.89
n2-highmem-32 256 244.4 32 31.85
n2-highmem-48 384 370.4 48 47.85
n2-highmem-64 512 496.8 64 63.77
n2-highmem-80 640 621.1 80 79.77
n2-highcpu-2 2 1.5 2 1.93
n2-highcpu-4 4 2.9 4 3.92
n2-highcpu-8 8 6.1 8 7.91
n2-highcpu-16 16 13.3 16 15.89
n2-highcpu-32 32 28.6 32 31.85
n2-highcpu-48 48 44.6 48 47.85
n2-highcpu-64 64 58.7 64 63.77
n2-highcpu-80 80 74.7 80 79.77
n2d-standard-2 8 6.1 2 1.93
n2d-standard-4 16 13.3 4 3.92
n2d-standard-8 32 28.6 8 7.91
n2d-standard-16 64 58.7 16 15.89
n2d-standard-32 128 118.6 32 31.85
n2d-standard-48 192 182.6 48 47.85
n2d-standard-64 256 244.4 64 63.77
n2d-standard-80 320 308.4 80 79.77
n2d-standard-96 384 370.4 96 95.69
n2d-standard-128 512 496.8 128 127.69
n2d-standard-224 896 877.1 224 223.69
n2d-highmem-2 16 13.3 2 1.93
n2d-highmem-4 32 28.6 4 3.92
n2d-highmem-8 64 58.7 8 7.91
n2d-highmem-16 128 118.6 16 15.89
n2d-highmem-32 256 244.4 32 31.85
n2d-highmem-48 384 370.4 48 47.85
n2d-highmem-64 512 496.8 64 63.77
n2d-highmem-80 640 621.1 80 79.77
n2d-highmem-96 780 761.1 96 95.69
n2d-highcpu-2 2 1.5 2 1.93
n2d-highcpu-4 4 2.9 4 3.92
n2d-highcpu-8 8 6.1 8 7.91
n2d-highcpu-16 16 13.3 16 15.89
n2d-highcpu-32 32 28.6 32 31.85
n2d-highcpu-48 48 44.6 48 47.85
n2d-highcpu-64 64 58.7 64 63.77
n2d-highcpu-80 80 74.7 80 79.77
n2d-highcpu-96 96 89.2 96 95.69
n2d-highcpu-128 128 118.6 128 127.69
n2d-highcpu-224 224 213.4 224 223.69

1 GKE では、e2-micro、e2-small、e2-medium の各マシンタイプで(ノード割り当て可能リソースとも呼ばれる)ユーザー ワークロードのスケジュール設定に使用できる割り当て可能 CPU リソースを減らすことが決定されました。詳細については、GKE リリースノートをご覧ください。

割り当て可能ローカル エフェメラル ストレージ リソース

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

通常、GKE は、単一のファイル システムと定期的なスキャンによってノードを構成します。サイズに依存するブートディスクの一部は、システムで使用するために予約されています。

エフェメラル ストレージはブートディスクの容量まで使用できますが、システム用に予約された部分とエビクションのしきい値は除きます。合計予約サイズは、次の式に従って、ブートディスクのサイズによって変わります。

10% * BOOT-DISK-CAPACITY + Min(50% * BOOT-DISK-CAPACITY, 6K + 35% * BOOT-DISK-CAPACITY, 100G)

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

ブートディスクの容量に応じてエフェメラル ストレージがどのように増加するかを示すグラフ。関係はほぼ線形です。