ノードプール

このページでは、Google Kubernetes Engine(GKE)でのノードプールの仕組みについて説明します。

ノードプールを管理する方法については、ノードプールの追加と管理をご覧ください。

概要

ノードプールは、クラスタ内で同じ構成を持つノードのグループです。ノードプールは、NodeConfig の仕様を使用します。プール内の各ノードには Kubernetes ノードラベル cloud.google.com/gke-nodepool が設定されます。これには値としてノードプールの名前が指定されます。ノードプールには 1 つまたは複数のノードを含めることができます。

クラスタの作成時に指定したノード数とノードタイプがデフォルトのノードプールになります。 その後、クラスタに別のサイズやタイプのカスタム ノードプールを追加できます。特定のノードプール内のノードはすべて同一になります。

たとえば、ローカル SSD最小 CPU プラットフォームプリエンプティブル VM、特定のノードイメージ、またはさまざまなマシンタイプを使用して、クラスタ内のノードプールを作成できます。カスタム ノードプールは、他より多くのリソース(メモリやローカル ディスク容量など)を必要とする Pod をスケジュールする必要がある場合に役立ちます。ポッドをスケジュールする場所をより細かく制御するには、Node Taints を使用できます。

クラスタ全体に影響を与えずに、ノードプールの作成、アップグレード、削除を個別に行うことができます。ノードプール内に単一ノードを構成することはできません。構成の変更は、ノードプール内のすべてのノードに影響します。

クラスタ内のノードプールのサイズを変更するには、ノードの追加または削除します。

デフォルトでは、新しいノードプールはすべて最新の安定したバージョンの Kubernetes を実行します。既存のノードプールは手動でアップグレードすることも、自動的にアップグレードすることもできます。また、クラスタ内の各ノードプールで複数の Kubernetes ノード バージョンを実行できます。ノードプールを個別に更新することも、特定のデプロイに対して異なるノードプールをターゲットとして指定することもできます。

特定のノードプールに Service をデプロイする

Service を定義すると、デプロイ先のノードプールを間接的に制御できます。ノードプールは、Service の構成ではなくPod の構成に依存します。

  • Pod マニフェストに nodeSelector を設定することによって、Pod を特定のノードプールに明示的にデプロイできます。こうすることで、Pod はそのノードプール内のノードでのみ実行されるようになります。例については、Pod を特定のノードプールにデプロイするをご覧ください。

  • コンテナのリソース リクエストを指定できます。Pod は、リソース リクエストを満たすノードでのみ実行されます。たとえば、Pod 定義に 4 つの CPU を必要とするコンテナが含まれている場合、Service は 2 つの CPU を持つノード上で動作する Pod を選択しません。

マルチゾーン クラスタまたはリージョン クラスタ内のノード

マルチゾーン クラスタまたはリージョン クラスタを作成すると、すべてのノードプールがこれらのゾーンに自動的に複製されます。新しいノードプールも、これらのゾーンに自動的に作成されます。同様に、あるゾーンからノードプールを削除すると、それらのノードプールが他のゾーンからも削除されます。

この乗法効果のため、ノードプールを作成すると、特定のリージョンに対するプロジェクトの割り当ての消費が増える場合があります。

ノードプールの削除

ノードプールを削除すると、GKE はノードプール内のすべてのノードをドレインします。このドレイン プロセスでは、ノードプール内の各ノードの GKE で Pod が強制排除されます。ノードプールの各ノードは、MAX_POD + 1 時間(PodDisruptionBudgets の場合)の猶予期間が割り当てられた Pod を強制排除することによりドレインされます。MAX_POD は、ノードに対してスケジュールされている Pod に設定される最大 terminationgraceperiodseconds で、上限は 1 時間に設定されます。

次のステップ