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

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

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

クラスタ マスター

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

クラスタ マスターと Kubernetes API

マスターは、クラスタの統合されたエンドポイントです。クラスタのすべての操作は Kubernetes API 呼び出しを経由して実行され、マスターでは Kubernetes API サーバー プロセスを実行してこれらのリクエストを処理します。Kubernetes API 呼び出しは、HTTP/gRPC を使用して直接行うことも、Kubernetes コマンドライン クライアント(kubectl)からコマンドを実行するか、GCP Console で UI を操作することによって間接的に行うこともできます。

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

マスターとノードのインタラクション

クラスタ マスターは、クラスタの全ノードについて、何を実行するかを決定する責任を担います。これには、コンテナ化されたアプリケーションなどのワークロードのスケジューリングや、ワークロードのライフサイクル、スケーリング、アップグレードの管理が含まれます。また、マスターによって、これらのワークロードのネットワーク リソースやストレージ リソースも管理されます。

マスターとノードの通信にも、Kubernetes API が使用されます。

マスターと gcr.io コンテナ レジストリとのインタラクション

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

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

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

GCP サービスの現在のステータスを確認するには、GCP ステータス ダッシュボードに移動します。

ノード

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

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

ノードでは、クラスタのワークロードを構成する Docker コンテナをサポートするために必要なサービスを実行します。この中には、Docker ランタイムと、マスターと通信しそのノードでスケジュールされた Docker コンテナを開始、実行する責任を担う Kubernetes ノード エージェント(kubelet)が含まれます。

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

ノード マシンタイプ

各ノードは標準の Compute Engine マシンタイプです。デフォルトのタイプは n1-standard-1 で、1 つの仮想 CPU と 3.75 GB のメモリを搭載しています。クラスタを作成するときに、デフォルト以外のマシンタイプを選択することもできます。

ノード OS イメージ

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

最小 CPU プラットフォーム

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

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

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

ポッドのリソースのリクエストを作成したり、リソースの使用量を制限したりできます。ポッドのリソースのリクエストやリソース使用量の制限については、コンテナのコンピューティング リソースを管理するをご覧ください。

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

kubectl describe node [NODE_NAME] | grep Allocatable -B 4 -A 3

返される出力には、エフェメラル ストレージ、メモリ、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

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

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

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

割り当て可能ローカル一時ストレージ リソースは、次の式で計算されます。この際、ストレージ容量の 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
このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Kubernetes Engine のドキュメント