Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

ノードプールの追加と管理

Autopilot Standard

このページでは、Google Kubernetes Engine（GKE）Standard クラスタで実行されるノードプールの追加、管理、スケーリング、アップグレード、削除を行う方法について説明します。これは、パフォーマンスとスケーラビリティのために GKE Standard クラスタを最適化するためです。Standard クラスタのノードプールには、Standard ノードプールと Autopilot 管理ノードプールが含まれます。ノードプールをアップグレードする方法に関するセクションを除き、このドキュメントの情報は Standard ノードプールに固有のものです。また、Pod を特定の Standard ノードプールにデプロイする方法と、ノードプールのアップグレードが実行中のワークロードに与える影響についても説明します。

このページは、クラスタの作成と構成、GKE へのワークロードのデプロイが必要なオペレーター、クラウドアーキテクト、デベロッパーを対象としています。 Google Cloudのコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE ユーザーロールとタスクをご覧ください。

このページを読む前に、ノードプールについて理解しておいてください。

始める前に

作業を始める前に、次のタスクが完了していることを確認してください。

Google Kubernetes Engine API を有効にする。

Google Kubernetes Engine API を有効化

このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。gcloud CLI をインストール済みの場合は、gcloud components update コマンドを実行して最新のバージョンを取得します。以前のバージョンの gcloud CLI では、このドキュメントのコマンドを実行できない場合があります。
注: gcloud CLI がすでにインストールされている場合には、必ず compute/region プロパティを設定してください。主にゾーンクラスタを使用する場合は、代わりに compute/zone を設定します。デフォルトのロケーションを設定することで、gcloud CLI のエラー（One of [--zone, --region] must be supplied: Please specify location など）を防止できます。クラスタのロケーションが設定したデフォルトと異なる場合は、特定のコマンドでロケーションの指定が必要になることがあります。

既存の Standard クラスタがあることを確認します。

GKE 用の IAM サービスアカウントを設定する

GKE は、ノードに接続されている IAM サービスアカウントを使用して、ロギングやモニタリングなどのシステムタスクを実行します。これらのノードサービスアカウントには、プロジェクトに対する Kubernetes Engine デフォルトノードサービスアカウント（roles/container.defaultNodeServiceAccount）ロールが最低限必要です。デフォルトでは、GKE はプロジェクトに自動的に作成される Compute Engine のデフォルトのサービスアカウントをノードサービスアカウントとして使用します。

Compute Engine のデフォルトサービスアカウントに roles/container.defaultNodeServiceAccount ロールを付与する手順は次のとおりです。

コンソール

[ようこそ] ページに移動します。
[ようこそ] に移動
[プロジェクト番号] フィールドで、 [クリップボードにコピー] をクリックします。
[IAM] ページに移動します。
[IAM] に移動
[ アクセスを許可] をクリックします。
[新しいプリンシパル] フィールドに次の値を指定します。
```
PROJECT_NUMBER-compute@developer.gserviceaccount.com
```
PROJECT_NUMBER は、コピーしたプロジェクト番号に置き換えます。
[ロールを選択] メニューで、[Kubernetes Engine デフォルトノードサービスアカウント] ロールを選択します。
[保存] をクリックします。

gcloud

Google Cloud プロジェクト番号を確認します。
```
gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)"
```
PROJECT_ID は、実際のプロジェクト ID に置き換えます。

出力は次のようになります。
```
12345678901
```
Compute Engine のデフォルトサービスアカウントに roles/container.defaultNodeServiceAccount ロールを付与します。
```
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
    --role="roles/container.defaultNodeServiceAccount"
```
PROJECT_NUMBER は、前の手順のプロジェクト番号に置き換えます。

Standard クラスタにノードプールを追加する

GKE Standard クラスタに新しいノードプールを追加するには、gcloud CLI、 Google Cloud コンソール、または Terraform を使用します。GKE は、スケーリング要件に基づいてクラスタ内のノードプールを自動的に管理するノード自動プロビジョニングもサポートしています。

ベストプラクティス:

ノードプール用に Compute Engine のデフォルトのサービスアカウントの代わりに使用する最小権限の Identity and Access Management（IAM）サービスアカウントを作成します。最小権限のみのサービスアカウントを作成する手順については、クラスタのセキュリティの強化をご覧ください。

gcloud

ノードプールを作成するには、gcloud container node-pools create コマンドを実行します。

gcloud container node-pools create POOL_NAME \
    --cluster CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --service-account SERVICE_ACCOUNT

次のように置き換えます。

POOL_NAME: 新しいノードプールの名前。
CLUSTER_NAME: 既存のクラスタの名前。
CONTROL_PLANE_LOCATION: クラスタのコントロールプレーンの Compute Engine のロケーション。リージョンクラスタの場合はリージョン、ゾーンクラスタの場合はゾーンを指定します。
SERVICE_ACCOUNT: ノードで使用する IAM サービスアカウントの名前。
Compute Engine のデフォルトのサービスアカウントの代わりに、ノードで使用できる最小権限の IAM サービスアカウントを指定することを強くおすすめします。最小権限のサービスアカウントを作成する方法については、最小権限のサービスアカウントを使用するをご覧ください。

gcloud CLI でカスタムサービスアカウントを指定するには、コマンドに次のフラグを追加します。
```
--service-account=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com
```
SERVICE_ACCOUNT_NAME は、最小権限のサービスアカウントの名前に置き換えます。

指定できるオプションのフラグの完全なリストについては、gcloud container node-pools create のドキュメントをご覧ください。

出力は次のようになります。

Creating node pool POOL_NAME...done.
Created [https://container.googleapis.com/v1/projects/PROJECT_ID/zones/us-central1/clusters/CLUSTER_NAME/nodePools/POOL_NAME].
NAME: POOL_NAME
MACHINE_TYPE: e2-medium
DISK_SIZE_GB: 100
NODE_VERSION: 1.21.5-gke.1302

この出力で、ノードで実行されているマシンタイプや GKE バージョンなど、ノードプールの詳細が表示されます。

ノードプールが正常に作成されても、サーバーからステータスが報告されず、gcloud コマンドがタイムアウトになる場合があります。プロビジョニングが完了していないノードプールを含め、すべてのノードプールのステータスを確認するには、次のコマンドを使用します。

gcloud container node-pools list --cluster CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

コンソール

既存の Standard クラスタにノードプールを追加する手順は次のとおりです。

Google Cloud コンソールで [Google Kubernetes Engine] ページに移動します。

Google Kubernetes Engine に移動
クラスタのリストで、変更する Standard クラスタの名前をクリックします。
[ノード] タブをクリックします。
[ユーザー管理のノードプールを作成] をクリックします。
ノードプールを構成します。
ナビゲーションメニューで [セキュリティ] をクリックします。
必要に応じて、ノードにカスタム IAM サービスアカウントを指定します。
1. [詳細設定] ページで、[セキュリティ] セクションを開きます。
2. [サービスアカウント] メニューで、目的のサービスアカウントを選択します。
Compute Engine のデフォルトのサービスアカウントの代わりに、ノードで使用できる最小権限の IAM サービスアカウントを指定することを強くおすすめします。最小権限のサービスアカウントを作成する方法については、最小権限のサービスアカウントを使用するをご覧ください。

[作成] をクリックしてノードプールを追加します。

Terraform

次のいずれかの例を使用します。

Compute Engine のデフォルトの IAM サービスアカウントを使用するノードプールを追加します。

resource "google_container_node_pool" "default" {
  name    = "gke-standard-regional-node-pool"
  cluster = google_container_cluster.default.name

  node_config {
    service_account = google_service_account.default.email
  }
}

カスタム IAM サービスアカウントを使用するノードプールを追加します。

IAM サービスアカウントを作成し、プロジェクトに対する roles/container.defaultNodeServiceAccount ロールを付与します。

resource "google_service_account" "default" {
  account_id   = "service-account-id"
  display_name = "Service Account"
}

data "google_project" "project" {
}

resource "google_project_iam_member" "default" {
  project = data.google_project.project.project_id
  role    = "roles/container.defaultNodeServiceAccount"
  member  = "serviceAccount:${google_service_account.default.email}"
}

新しいサービスアカウントを使用するノードプールを作成します。

resource "google_container_node_pool" "default" {
  name    = "gke-standard-regional-node-pool"
  cluster = google_container_cluster.default.name

  node_config {
    service_account = google_service_account.default.email
  }
}

Terraform の使用方法の詳細については、GKE での Terraform のサポートをご覧ください。

Standard クラスタ内のノードプールを表示する

gcloud

Standard クラスタのすべてのノードプールを一覧取得するには、gcloud container node-pools list コマンドを実行します。

gcloud container node-pools list --cluster CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

特定のノードプールの詳細を表示するには、gcloud container node-pools describe コマンドを実行します。

gcloud container node-pools describe POOL_NAME \
    --cluster CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

以下を置き換えます。

CLUSTER_NAME: クラスタの名前。
POOL_NAME: 表示するノードプールの名前。
CONTROL_PLANE_LOCATION: クラスタのコントロールプレーンの Compute Engine のロケーション。リージョンクラスタの場合はリージョン、ゾーンクラスタの場合はゾーンを指定します。

コンソール

Standard クラスタのノードプールを表示する手順は次のとおりです。

Google Cloud コンソールで [Google Kubernetes Engine] ページに移動します。

Google Kubernetes Engine に移動
クラスタリストで、Standard クラスタの名前をクリックします。
[ノード] タブをクリックします。
[ノードプール] で、表示するノードプールの名前をクリックします。

ノードプールをスケーリングする

ノードプールをスケールアップまたはスケールダウンして、パフォーマンスと費用を最適化できます。GKE Standard ノードプールを使用すると、ノードプール内のノード数を変更してノードプールを水平方向にスケーリングできます。また、ノードのマシン属性構成を変更してノードプールを垂直方向にスケーリングできます。

ノード数を変更して水平方向にスケーリングする

gcloud

クラスタのノードプールのサイズを変更するには、gcloud container clusters resize コマンドを実行します。

gcloud container clusters resize CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --node-pool POOL_NAME \
    --num-nodes NUM_NODES

以下を置き換えます。

CLUSTER_NAME: サイズを変更するクラスタの名前。
CONTROL_PLANE_LOCATION: クラスタのコントロールプレーンの Compute Engine のロケーション。リージョンクラスタの場合はリージョン、ゾーンクラスタの場合はゾーンを指定します。
POOL_NAME: サイズを変更するノードプールの名前。
NUM_NODES: ゾーンクラスタ内のプール内のノードの数。マルチゾーンクラスタまたはリージョンクラスタを使用する場合、NUM_NODES はノードプールが存在している各ゾーンのノード数です。

各ノードプールに対してこのコマンドを繰り返します。クラスタにノードプールが 1 つしかない場合は、--node-pool フラグを省略します。

Console

クラスタのノードプールのサイズを変更する手順は次のとおりです。

Google Cloud コンソールで [Google Kubernetes Engine] ページに移動します。

Google Kubernetes Engine に移動
クラスタのリストで、変更する Standard クラスタの名前をクリックします。
[ノード] タブをクリックします。
[ノードプール] セクションで、サイズを変更するノードプールの名前をクリックします。
[サイズ変更] をクリックします。
[ノード数] フィールドに、ノードプールに含めるノード数を入力し、[サイズ変更] をクリックします。
必要に応じてノードプールごとに同じ操作を繰り返します。

ノードマシンの属性を変更して垂直方向にスケーリングする

ノードプールの構成済みのマシンタイプ、ディスクタイプ、ディスクサイズを変更できます。

これらのマシン属性を編集すると、GKE はノードプールに構成されたアップグレード戦略を使用して、ノードを新しい構成に更新します。Blue/Green アップグレード戦略を構成すると、移行の失敗時に元のノードをロールバックできるようにしながら、元のノードから新しいノードにワークロードを移行できます。ノードプールのアップグレード設定を調べて、構成した戦略が必要なノードの更新方法と一致していることを確認します。

次のコマンドで、ハイライト表示されているマシン属性の少なくとも 1 つを更新します。

gcloud container node-pools update POOL_NAME \
    --cluster CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --machine-type MACHINE_TYPE \
    --disk-type DISK_TYPE \
    --disk-size DISK_SIZE

変更しないマシン属性のフラグは省略します。ただし、少なくとも 1 つのマシン属性フラグを使用する必要があります。そうしないと、コマンドが失敗します。

次のように置き換えます。

POOL_NAME: サイズを変更するノードプールの名前。
CLUSTER_NAME: サイズを変更するクラスタの名前。
CONTROL_PLANE_LOCATION: クラスタのコントロールプレーンの Compute Engine のロケーション。リージョンクラスタの場合はリージョン、ゾーンクラスタの場合はゾーンを指定します。
MACHINE_TYPE: ノードに使用するマシンのタイプ。詳細については、gcloud container node-pools update をご覧ください。
DISK_TYPE: ノード VM ブートディスクのタイプ。マシンシリーズに応じて、pd-standard、pd-ssd、pd-balanced、hyperdisk-balanced のいずれかになります。hyperdisk-extreme または hyperdisk-throughput をブートディスクとして使用することはできません。マシンシリーズがサポートするディスクの詳細については、マシンシリーズの比較の表をご覧ください。
DISK_SIZE: ノード VM ブートディスクのサイズ（GB）。デフォルトは 100 GB です。

この変更を行うにはノードの再作成が必要になり、実行中のワークロードが中断する可能性があります。この変更について詳しくは、メンテナンスポリシーに準拠せずにノードアップグレード戦略を使用してノードを再作成する手動変更の表で対応する行をご覧ください。ノードの更新の詳細については、ノードの更新による中断の計画をご覧ください。

ノードプールをアップグレードする

デフォルトでは、Standard ノードプールに対して自動アップグレードが有効になっています。また、Standard クラスタ内の Autopilot 管理のノードプールすべてに対して、常に自動アップグレードが有効になっています。ノードの自動アップグレードにより、クラスタのコントロールプレーンとノードのバージョンが同期され、Kubernetes バージョンスキューポリシーに準拠していることが保証されます。これにより、コントロールプレーンとその 2 つ前までのマイナーバージョンのノードとの適合性が保証されます。たとえば、Kubernetes 1.34 コントロールプレーンは Kubernetes 1.32 ノードと互換性があります。デフォルトでは、GKE は一度に 1 つのノードプールのみを自動的にアップグレードします。複数のノードプールを同時に自動アップグレードするには、ノードプールの同時アップグレードを構成します（プレビュー）。

ベストプラクティス:

Standard ノードプールでノードの自動アップグレードを無効にすることは避けます。有効にしておくことで、クラスタは前の段落で説明したアップグレードのメリットを享受できます。

GKE Standard ノードプールのアップグレードでは、サージアップグレード、Blue/Green アップグレード、自動スケーリングされる Blue/Green アップグレード（プレビュー）など、3 つの構成可能なアップグレード戦略から選択できます。Standard クラスタの Autopilot 管理ノードプールでは、常にサージアップグレードが使用されます。

Standard ノードプールでは、いずれかの戦略を選択したうえで、クラスタ環境のニーズに合うようにパラメータを使用して戦略を調整します。

ノードのアップグレードの仕組み

ノードがアップグレードされている間、GKE はそのノードへの新しい Pod のスケジュールを停止し、実行中の Pod を他のノードにスケジュールしようとします。これは、ノードプールで機能を有効または無効にする場合など、ノードの再作成を行う他のイベントの場合と同様です。

ノードの自動または手動アップグレード中、PodDisruptionBudgets（PDB）と Pod の停止猶予期間が適用されるのは、最大 1 時間までです。1 時間が経過しても、ノードで実行中の Pod を新しいノードにスケジュールできない場合、GKE はアップグレードを開始します。maxUnavailable フィールドを 0 または 0% に設定するか、minAvailable フィールドを 100% またはレプリカ数に設定して、すべてのレプリカを常に使用できるように PDB を構成している場合でも、この動作は適用されます。これらすべてのシナリオにおいて、GKE は 1 時間後に Pod を削除し、ノードを削除できるようにします。

ベストプラクティス:

Standard ノードプールで実行中のワークロードの正常終了にさらに柔軟性が必要な場合は、Blue/Green アップグレードを使用すると、PDB チェックをデフォルトの 1 時間より長くする追加のソーク時間を設定できます。

ノードが停止されるときの一般的な動作については、Pod に関するトピックをご覧ください。

アップグレードは、すべてのノードが再作成され、クラスタが新しい状態になったときにはじめて完了します。新しくアップグレードされたノードがコントロールプレーンに登録されると、GKE はノードがスケジュール可能であるとマークします。

新しいノードインスタンスでは、新しい Kubernetes バージョンと次のものが実行されます。

ノードプールのアップグレードが完了したと見なされるには、ノードプール内のすべてのノードが再作成されている必要があります。アップグレードが開始されたものの完了せず、部分的にアップグレードされた状態になっている場合、ノードプールのバージョンにすべてのノードのバージョンが反映されていない可能性があります。詳細については、ノードプールのアップグレードが不完全で一部のノードのバージョンがノードプールのバージョンと一致していないをご覧ください。ノードプールのアップグレードが終了したかどうかは、ノードプールのアップグレードステータスで確認します。アップグレードオペレーションが保持期間を超えている場合は、各ノードのバージョンとノードプールのバージョンが一致しているかどうかを確認します。

アップグレードする前にデータを永続ディスクに保存する

ノードプールをアップグレードする前に、保持する必要があるデータについて、[永続ディスク] を使用する [永続ボリューム] を使用して Pod に保存されていることを確認する必要があります。永続ディスクは、アップグレード時にデータを消去せずにマウント解除され、そのデータは Pod 間で転送されます。

永続ディスクには次の制限があります。

ポッドを実行しているノードが Compute Engine VM であること。
これらの VM は、Persistent Disk と同じ Compute Engine プロジェクトおよびゾーンに存在する必要があります。

既存のノードインスタンスに永続ディスクを追加する方法については、Compute Engine ドキュメントのゾーン永続ディスクの追加またはサイズ変更をご覧ください。

ノードプールの手動アップグレード

Standard クラスタの Standard ノードプールまたは Autopilot 管理ノードプールのバージョンは、手動でアップグレードできます。コントロールプレーンのバージョンと一致させるか、引き続き使用可能でコントロールプレーンと適合性のある以前のバージョンを使用できます。ノードプールの同時アップグレードを構成すると、GKE が複数のノードプールを同時にアップグレードできるのと同様に、複数のノードプールを同時に手動でアップグレードできます。

GKE がノードプールをアップグレードすると（手動または自動）、kubectl を使用して個々のノードに追加したラベルが削除されます。ノードを再作成する GKE クラスタの他の種類の変更でも、ラベルが削除されます。ラベルが失われないようにするには、代わりにラベルをノードプールに適用します。

ノードプールを手動でアップグレードする前に、次の条件を検討してください。

ノードプールをアップグレードすると、そのノードプールで実行中のワークロードが中断される場合があります。これを回避するには、必要なバージョンで新しいノードプールを作成し、ワークロードを移行します。移行後、古いノードプールは削除できます。
エラー状態の Ingress があるノードプールをアップグレードすると、インスタンスグループが同期されません。この問題に対処するには、まず、kubectl get ing コマンドでステータスを確認します。インスタンスグループが同期されていない場合は、Ingress の作成に使用したマニフェストを再適用します。

ノードプールは、コントロールプレーンと適合性のあるバージョンに手動でアップグレードできます。

Standard ノードプールの場合、 Google Cloud コンソールまたは Google Cloud CLI を使用できます。
Autopilot 管理ノードプールの場合、Google Cloud CLI のみを使用できます。

コンソール

Google Cloud コンソールを使用して Standard ノードプールをアップグレードするには、次の手順を行います。

Google Cloud コンソールで [Google Kubernetes Engine] ページに移動します。

Google Kubernetes Engine に移動
クラスタの名前をクリックします。
[クラスタの詳細] ページで [ノード] タブをクリックします。
[ノードプール] セクションで、アップグレードするノードプールの名前をクリックします。
[ 編集] をクリックします。
[ノードのバージョン] で [変更] をクリックします。
[ノードのバージョン] プルダウンリストから必要なバージョンを選択し、[変更] をクリックします。

ノードのバージョンが変更されるまで数分かかることがあります。

gcloud

このセクションのコマンドでは、次の変数を使用します。

CLUSTER_NAME: アップグレードするノードプールのクラスタの名前。
NODE_POOL_NAME: アップグレードするノードプールの名前。
CONTROL_PLANE_LOCATION: コントロールプレーンのロケーション（リージョンまたはゾーン）。たとえば、us-central1 や us-central1-a です。
VERSION: ノードのアップグレード後の Kubernetes バージョン。たとえば、--cluster-version=1.34.1-gke.1293000 や cluster-version=latest です。

ノードプールをアップグレードします。

gcloud container clusters upgrade CLUSTER_NAME \
  --node-pool=NODE_POOL_NAME \
  --location=CONTROL_PLANE_LOCATION

ノードで GKE の別のバージョンを指定するには、オプションの --cluster-version フラグを使用します。

gcloud container clusters upgrade CLUSTER_NAME \
  --node-pool=NODE_POOL_NAME \
  --location=CONTROL_PLANE_LOCATION \
  --cluster-version VERSION

バージョンの指定の詳細については、バージョニングに関する記事をご覧ください。

詳細については、gcloud container clusters upgrade のドキュメントをご覧ください。

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

Pod マニフェストで nodeSelector を使用して、Pod を特定のノードプールに明示的にデプロイできます。nodeSelector は、ラベルが一致するノードに Pod のスケジュールを設定します。

すべての GKE ノードプールには、cloud.google.com/gke-nodepool: POOL_NAME という形式のラベルがあります。次の例に示すように、このラベルを Pod の nodeSelector フィールドに追加します。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
    cloud.google.com/gke-nodepool: POOL_NAME

詳細は、ノードに Pod を割り当てるをご覧ください。

ノードセレクタの代わりに、ノードアフィニティを使用できます。Pod が制約を満たそうと試みる一方で、制約を満たせない場合でも Pod のスケジュールが設定される「ソフト」ルールを適用したい場合は、ノードアフィニティを使用します。詳細は、ノードアフィニティをご覧ください。コンテナのリソースリクエストを指定することもできます。

ノードプールをダウングレードする

GKE がノードプールのアップグレードを完了した場合、ノードプールをダウングレードできます。GKE は、部分的にアップグレードされたノードプールをダウングレードできません。ロールバックのみ可能です。部分的にアップグレードされたノードプールのダウングレードをトリガーしようとすると、GKE はそのオペレーションでノードプール内のノードを更新しません。ノードプールが完全にアップグレードされておらず、ロールバックのみ可能な状態かどうかを確認するには、まずノードプールのアップグレードステータスを確認します。アップグレードがキャンセルされたか失敗した場合は、ノードプール内のノードを調べて、以前のバージョンを実行しているノードがまだあるかどうかを確認することで、ノードプールのアップグレードが完了していないことを確認できます。

ノードプールのアップグレードが完了せず、アップグレードされたノードを以前のバージョンにロールバックする場合は、ノードプールのアップグレードをロールバックするの手順に沿って操作します。ノードプールのアップグレードが完了し、ワークロードで問題が発生したため、アップグレードを元に戻す場合は、このセクションの手順に沿ってノードプールを以前のバージョンにダウングレードできます。ノードプールをダウングレードする前に、制限事項を確認してください。

ベストプラクティス:

ワークロードに影響するノードプールのアップグレードのリスク軽減を最適化する必要がある場合は、ノードの Blue/Green アップグレード戦略を使用します。この戦略では、アップグレードが失敗した場合に、進行中のアップグレードを元のノードにロールバックできます。

ダウングレード後に GKE によってノードプールが自動的にアップグレードされないようにするには、メンテナンスの除外をクラスタに設定します。
以前のバージョンにダウングレードするには、ノードプールを手動でアップグレードするの手順に沿って、以前のバージョンを指定します。

ノードプールの削除

ノードプールを削除すると、ノードと実行中のワークロードがすべて削除されます。デフォルトでは、GKE はノードプールを削除するときに PodDisruptionBudget の設定を無視します。この設定を変更する方法については、ノードプールの削除時に PDB を尊重するようにノードプールを更新するをご覧ください。

ノードセレクタの操作など、ノードプールの削除がワークロードに与える影響の詳細については、ノードプールの削除をご覧ください。

削除できるのは Standard ノードプールのみです。Standard クラスタで実行される Autopilot 管理ノードプールは削除できません。これらのノードプールが不要になると、GKE によって自動的にクリーンアップされます。

gcloud CLI またはGoogle Cloud コンソールを使用してノードプールを削除します。

gcloud

ノードプールを削除するには、gcloud container node-pools delete コマンドを実行します。

gcloud container node-pools delete POOL_NAME \
    --cluster CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

次のように置き換えます。

POOL_NAME: 削除するノードプールの名前。
CLUSTER_NAME: クラスタの名前。
CONTROL_PLANE_LOCATION: クラスタのコントロールプレーンの Compute Engine ロケーション。リージョンクラスタの場合はリージョン、ゾーンクラスタの場合はゾーンを指定します。

コンソール

ノードプールを削除する手順は次のとおりです。

Google Cloud コンソールで [Google Kubernetes Engine] ページに移動します。

Google Kubernetes Engine に移動
クラスタのリストで、変更する Standard クラスタの名前をクリックします。
[ノード] タブをクリックします。
[ノードプール] セクションで、削除するノードプールの横にあるをクリックします。
確認のメッセージが表示されたら、[削除] をクリックします。

ノードプールの削除時に PDB を尊重するようにノードプールを更新する

デフォルトでは、GKE はノードプールを削除するときに PodDisruptionBudget の設定を無視します。ただし、ノードプールの削除中に GKE が PDB を最大 1 時間尊重するように、ノードプールの構成を更新できます。PDB を尊重することで、ワークロードはクラスタ内の他のノードに移動できます。この設定は、クラスタの削除時のノードプールの削除には影響しません。

ノードプールの設定を更新するには、次の gcloud CLI コマンドを実行します。

gcloud container node-pools update POOL_NAME
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --respect-pdb-during-node-pool-deletion

次のように置き換えます。

POOL_NAME: ノードプールの名前。
CLUSTER_NAME: クラスタの名前。
CONTROL_PLANE_LOCATION: クラスタのコントロールプレーンの Compute Engine ロケーション。リージョンクラスタの場合はリージョン、ゾーンクラスタの場合はゾーンを指定します。

ノードプールを追加するときに、--respect-pdb-during-node-pool-deletion フラグを使用することもできます。

この構成を削除して、ノードプールの削除時に PDB を尊重しないデフォルト設定を使用するには、次のセクションをご覧ください。

ノードプールの削除時に PDB を無視するようにノードプールを更新する

ノードプールを更新して、ノードプールの削除時に PDB を尊重しないデフォルト設定に戻すことができます。

設定を更新するには、次の gcloud CLI コマンドを実行します。

gcloud container node-pools update POOL_NAME
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --no-respect-pdb-during-node-pool-deletion

次のように置き換えます。

POOL_NAME: ノードプールの名前。
CLUSTER_NAME: クラスタの名前。
CONTROL_PLANE_LOCATION: クラスタのコントロールプレーンの Compute Engine ロケーション。リージョンクラスタの場合はリージョン、ゾーンクラスタの場合はゾーンを指定します。

ノードを別のマシンタイプに移行する

マシンタイプ間でワークロードを移動するさまざまな方法（新しいマシンタイプに移行する方法など）については、ノードを別のマシンタイプに移行するをご覧ください。

ノードプール間でワークロードを移行する

ワークロードをあるノードプールから別のノードプールに移行するには、ノードプール間でワークロードを移行するをご覧ください。たとえば、既存のノードプールを新しいノードプールに置き換え、ワークロードを古いノードから新しいノードに確実に移行するには、次の操作を行います。

トラブルシューティング

トラブルシューティングについては、Standard ノードプールのトラブルシューティングとノード登録のトラブルシューティングをご覧ください。

ノードプールの追加と管理 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

始める前に

GKE 用の IAM サービス アカウントを設定する

コンソール

gcloud

Standard クラスタにノードプールを追加する

gcloud

コンソール

Terraform

Standard クラスタ内のノードプールを表示する

gcloud

コンソール

ノードプールをスケーリングする

ノード数を変更して水平方向にスケーリングする

gcloud

Console

ノードマシンの属性を変更して垂直方向にスケーリングする

ノードプールをアップグレードする

ノードのアップグレードの仕組み

アップグレードする前にデータを永続ディスクに保存する

ノードプールの手動アップグレード

コンソール

gcloud

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

ノードプールをダウングレードする

ノードプールの削除

gcloud

コンソール

ノードプールの削除時に PDB を尊重するようにノードプールを更新する

ノードプールの削除時に PDB を無視するようにノードプールを更新する

ノードを別のマシンタイプに移行する

ノードプール間でワークロードを移行する

トラブルシューティング

次のステップ

ノードプールの追加と管理

GKE 用の IAM サービスアカウントを設定する