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

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

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

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

クラスタ マスター

クラスタ マスターは、Kubernetes API サーバー、スケジューラ、コアリソース コントローラといった Kubernetes コントロール プレーンのプロセスを実行します。クラスタを作成または削除したときに、マスターのライフサイクルが 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 コンテナ レジストリとのインタラクション

クラスタを作成または更新した場合、マスター(およびノード)で実行されている 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 マシンタイプです。デフォルトのタイプは n1-standard-1 で、これは 1 つの仮想 CPU と 3.75 GB のメモリを搭載しています。クラスタを作成するときに、デフォルト以外のマシンタイプを選択できます。

ノード 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 4 -A 3
    

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

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

割り当て可能メモリと 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%

GKE は、kubelet eviction 用のノードごとにさらに 100 MiB のメモリを予約します。

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

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

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

マシンタイプ メモリ容量(GB) 割り当て可能メモリ(GB) CPU 容量(コア数) 割り当て可能 CPU(コア数)
f1-micro 0.6 0.24 1 0.94
g1-small 1.7 1.2 1 0.94
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

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

GKE バージョン 1.10 以降では、CPU やメモリリソースと同様にローカル エフェメラル ストレージ リソースも管理できます。ローカル ストレージのシステム予約では、主にコンテナ イメージで使用されるディスク容量を予約します。

予約済みストレージの一部がノードで使用されない場合、Pod はその分の容量を使用できます。この場合、あらゆるシナリオでディスク容量の使用は制限されません。

割り当て可能ローカル エフェメラル ストレージ リソースは、次の式で計算されます。この際、ストレージ容量の 10% がエビクションのしきい値となります。

Allocatable = Capacity - Reserved - Eviction Threshold

ディスク容量(GB) 予約済み(GB) 割り当て可能(GB)
8 4 3.2
16 8 6.4
32 16 12.8
64 28.4 29.2
128 50.8 64.4
256 95.6 134.8
512 100 360.8
1024 100 821.6
2048 100 1743.2
4096 100 3586.4