クラスタまたはノードプールの手動アップグレード

Autopilot Standard

Google Kubernetes Engine（GKE）クラスタと GKE Standard ノードプールでは、自動アップグレードがデフォルトで有効になっています。

このページでは、GKE クラスタのコントロールプレーンまたはノードのアップグレードとダウングレードを手動でリクエストする方法について説明します。次の方法を使用して、バージョンを手動でアップグレードできます。

Autopilot: コントロールプレーンのバージョンをアップグレードします。
Standard: コントロールプレーンのバージョンとノードプールのバージョンをアップグレードします。

クラスタをアップグレードするために、GKE はコントロールプレーンとノードで実行されているバージョンを更新します。クラスタが新しいマイナーバージョン（1.24 から 1.25 など）または新しいパッチバージョン（1.24.2-gke.100 から 1.24.5-gke.200 など）にアップグレードされます。詳細については、GKE のバージョニングとサポートをご覧ください。

クラスタの自動アップグレードと手動アップグレードの仕組みをご確認ください。メンテナンスの時間枠と除外対象を構成することで、自動アップグレードのタイミングを管理することもできます。

新しいバージョンの GKE は定期的に発表されています。また、クラスタ通知を使用して、特定のクラスタのそれぞれで利用可能な新しいバージョンに関する通知を受け取ることができます。クラスタの特定の自動アップグレードターゲットを確認するには、クラスタのアップグレードに関する情報の取得を行います。

利用可能なバージョンについては、バージョニングに関する記事をご覧ください。クラスタの詳細については、クラスタのアーキテクチャをご覧ください。クラスタのアップグレードに関するガイダンスについては、クラスタのアップグレードに関するベストプラクティスをご覧ください。

始める前に

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

Google Kubernetes Engine API を有効にする。

Google Kubernetes Engine API の有効化

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

既存の Autopilot クラスタまたは Standard クラスタがあることを確認します。新しいクラスタを作成するには、Autopilot クラスタの作成をご覧ください。

データを永続ディスクに保存する

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

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

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

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

アップグレードについて

クラスタのコントロールプレーンとノードは個別にアップグレードされます。

クラスタのコントロールプレーンは、クラスタがリリースチャンネルに登録されているかどうかにかかわらず、定期的にアップグレードされます。

制限事項

アルファクラスタはアップグレードできません。

サポート対象のバージョン

新しいバージョンがリリースされたときや、古いバージョンが廃止されたときに、リリースノートで通知されます。次のコマンドを使用すると、サポート対象のクラスタとノードのバージョンをいつでも確認できます。

gcloud container get-server-config

クラスタがリリースチャンネルに登録されている場合は、コントロールプレーンと同じマイナーバージョンの別のリリースチャンネルのパッチバージョンにアップグレードできます。たとえば、クラスタを Regular チャンネルのバージョン 1.21.12-gke.1700 から Rapid チャンネルの 1.21.13-gke.900 にアップグレードできます。詳細については、新しいチャンネルからのパッチバージョンの実行をご覧ください。すべての Autopilot クラスタがリリースチャンネルに登録されます。

ダウングレードの制限事項

特定のシナリオでは、クラスタのバージョンを以前のバージョンにダウングレードできます。

バージョンが同じマイナーバージョンの旧パッチリリースであれば、クラスタコントロールプレーンのアップグレードの失敗を回避するために、コントロールプレーンを以前のパッチリリースにダウングレードできます。たとえば、クラスタのコントロールプレーンが GKE 1.25.3-gke.400 を実行している場合、そのバージョンがまだ使用可能であれば、コントロールプレーンを 1.25.2-gke.100 にダウングレードできます。

Kubernetes クラスタコントロールプレーンを以前のマイナーバージョンにダウングレードすることはできません。たとえば、コントロールプレーンが GKE バージョン 1.25 を実行している場合、1.24 にダウングレードすることはできません。これを行おうとすると、次のエラーメッセージが表示されます。

ERROR: (gcloud.container.clusters.upgrade) ResponseError: code=400,
message=Master cannot be upgraded to "1.24.3-gke.100": specified version is not
newer than the current version.

クラスタのコントロールプレーンのマイナーバージョンはダウングレードできないため、新しいマイナーバージョンが利用可能になり、それがデフォルトのバージョンになる前に、テスト環境のクラスタでマイナーバージョンのアップグレードをテストして検証することをおすすめします。これは、次のマイナーバージョンの重要な変更（非推奨の API や機能の削除など）により、クラスタに影響が生じる可能性がある場合に特におすすめします。

ノードプールのアップグレードの失敗を回避するために、ノードプールを以前のパッチリリースまたはマイナーバージョンにダウングレードできます。ノードは、クラスタコントロールプレーンのバージョンより 2 つ前のマイナーバージョンにダウングレードしないでください。

クラスタのアップグレード

クラスタとノードは自動的にアップグレードされます。クラスタとそのノードに適用される自動アップグレードの内容をより細かく管理するには、リリースチャンネルに登録します。すべての Autopilot クラスタがリリースチャンネルに自動的に登録されます。

クラスタの GKE バージョンの管理についての詳細は、アップグレードに関する記事をご覧ください。

手動アップグレードは、新しいバージョンの提供後であればいつでも開始できます。

コントロールプレーンの手動アップグレード

クラスタのアップグレードを開始すると、コントロールプレーンに再びアクセスできるようになるまで、数分間はクラスタの構成を変更できません。コントロールプレーンのアップグレード中のダウンタイムを防ぐ必要がある場合は、Autopilot クラスタまたは Standard リージョンクラスタの使用を検討してください。コントロールプレーンのアップグレード中にワークロードが使用可能のままになるため、このオペレーションはワークロードが実行されるワーカーノードの可用性には影響しません。

Autopilot または Standard のコントロールプレーンは、 Google Cloud コンソールまたは Google Cloud CLI を使用して手動でアップグレードできます。

gcloud

クラスタのコントロールプレーンで使用可能なバージョンを確認するには、次のコマンドを実行します。

gcloud container get-server-config

デフォルトのクラスタバージョンにアップグレードするには、次のコマンドを実行します。

gcloud container clusters upgrade CLUSTER_NAME --master

デフォルト以外の特定のバージョンにアップグレードするには、--cluster-version フラグを指定します。次に例を示します。

gcloud container clusters upgrade CLUSTER_NAME --master \
    --cluster-version VERSION

VERSION は、クラスタのアップグレード後のバージョンに置き換えます。1.18.17-gke.100 のように特定のバージョンを使用することも、latest のようにバージョンのエイリアスを使用することもできます。詳細については、クラスタバージョンの指定をご覧ください。

コンソール

クラスタコントロールプレーンを手動で更新するには、次の手順に沿って操作します。

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

Google Kubernetes Engine に移動
クラスタの名前をクリックします。
[クラスタの基本] で、[バージョン] の横にある [ アップグレード可能] をクリックします。
目的のバージョンを選択し、[変更を保存] をクリックします。

Standard コントロールプレーンをアップグレードした後、そのノードをアップグレードできます。デフォルトでは、 Google Cloud コンソールで作成した Standard ノードでは自動アップグレードが有効になります。このため、アップグレードは自動的に行われます。Autopilot では、常にノードは自動的にアップグレードされます。

クラスタのダウングレード

ダウングレード後にコントロールプレーンが自動的にアップグレードされないように、ダウングレードする前にメンテナンスの除外を設定します。
クラスタコントロールプレーンを以前のパッチバージョンにダウングレードします。
```
 gcloud container clusters upgrade CLUSTER_NAME \
     --master --cluster-version VERSION
```

クラスタの自動アップグレードの無効化

GKE では、インフラストラクチャのセキュリティは優先度の高い事項であるため、コントロールプレーンのアップグレードは定期的に実施され、無効にはできません。ただし、メンテナンスの時間枠と除外を適用すると、コントロールプレーンとノードのアップグレードを一時停止できます。

推奨されませんが、ノードの自動アップグレードを無効にすることは可能です。

最近のコントロールプレーンのアップグレード履歴を確認する

クラスタの最近の自動アップグレード履歴のスナップショットを取得するには、クラスタのアップグレードに関する情報の取得を行います。

または、最近のオペレーションを一覧表示して、コントロールプレーンがいつアップグレードされたかを確認することもできます。

gcloud container operations list --filter="TYPE:UPGRADE_MASTER AND TARGET:CLUSTER_NAME"

CLUSTER_NAME は、使用するクラスタの名前に置き換えます。

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

デフォルトでは、クラスタのノードで自動アップグレードが有効になっています。ノードの自動アップグレードにより、クラスタのコントロールプレーンとノードのバージョンが同期されており、Kubernetes バージョンスキューポリシーに準拠していることが保証されます。これにより、コントロールプレーンはそのコントロールプレーンの 2 つ前までのマイナーバージョンのノードと互換性が保証されています。たとえば、Kubernetes 1.29 コントロールプレーンは Kubernetes 1.27 ノードと互換性があります。

ベストプラクティス:

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

GKE ノードプールのアップグレードでは、サージアップグレードと Blue/Green アップグレードの 2 つの構成可能なアップグレード戦略を選択できます。

クラスタ環境のニーズに最適な戦略を選択し、戦略を調整するパラメータを使用します。

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

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

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

ベストプラクティス:

ワークロードを正常に終了する際に柔軟性が必要な場合は、Blue/Green アップグレードを使用すると、デフォルトの 1 時間を超えて PDB チェックを行うために追加のソーク時間が設定されます。

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

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

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

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

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

手動でアップグレードできるノードプールのバージョンは、コントロールプレーンと同じバージョンか、引き続き使用可能でコントロールプレーンと互換性のある以前のバージョンです。複数のノードプールを同時に手動でアップグレードできますが、GKE が自動で一度にアップグレードするノードプールは 1 つだけです。

ノードプールを手動でアップグレードすると、kubectl を使用して個々のノードに追加したラベルが削除されます。これを回避するには、ノードプールにラベルを適用します。

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

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

ノードプールは、 Google Cloud コンソールまたは Google Cloud CLI を使用して、コントロールプレーンと互換性のあるバージョンに手動でアップグレードできます。

gcloud

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

CLUSTER_NAME: アップグレードするノードプールのクラスタの名前。
NODE_POOL_NAME: アップグレードするノードプールの名前。
VERSION: ノードのアップグレード先の Kubernetes バージョン。たとえば、--cluster-version=1.7.2 や cluster-version=latest です。

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

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

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

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

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

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

コンソール

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

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

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

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

ノードプールのダウングレード

たとえば、ノードプールのアップグレードの失敗の可能性を軽減するために、ノードプールをダウングレードできます。ノードプールをダウングレードする前に、制限事項を確認してください。

ベストプラクティス:

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

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

サージアップグレードパラメータを変更する

サージアップグレードパラメータの変更の詳細については、サージアップグレードを構成するをご覧ください。

ノードプールのアップグレードステータスを確認する

アップグレードのステータスは、gcloud container operations で確認できます。

オペレーションの数が 5,000 件未満の場合は過去 12 日間、5,000 件以上の場合は過去 5,000 件の、クラスタ内の実行中のオペレーションと完了したオペレーションの全リストを表示します。

gcloud container operations list

各オペレーションには、開始時刻と終了時刻、ターゲットクラスタ、ステータスとともに、オペレーション ID とオペレーションタイプが割り当てられています。このリストの表示例を次に示します。

NAME                              TYPE                ZONE           TARGET              STATUS_MESSAGE  STATUS  START_TIME                      END_TIME
operation-1505407677851-8039e369  CREATE_CLUSTER      us-west1-a     my-cluster                          DONE    20xx-xx-xxT16:47:57.851933021Z  20xx-xx-xxT16:50:52.898305883Z
operation-1505500805136-e7c64af4  UPGRADE_CLUSTER     us-west1-a     my-cluster                          DONE    20xx-xx-xxT18:40:05.136739989Z  20xx-xx-xxT18:41:09.321483832Z
operation-1505500913918-5802c989  DELETE_CLUSTER      us-west1-a     my-cluster                          DONE    20xx-xx-xxT18:41:53.918825764Z  20xx-xx-xxT18:43:48.639506814Z

特定のオペレーションに関する詳細情報を取得するには、次のコマンドに示すようにオペレーション ID を指定します。

gcloud container operations describe OPERATION_ID

例:

gcloud container operations describe operation-1507325726639-981f0ed6
endTime: '20xx-xx-xxT21:40:05.324124385Z'
name: operation-1507325726639-981f0ed6
operationType: UPGRADE_CLUSTER
selfLink: https://container.googleapis.com/v1/projects/.../kubernetes-engine/docs/zones/us-central1-a/operations/operation-1507325726639-981f0ed6
startTime: '20xx-xx-xxT21:35:26.639453776Z'
status: DONE
targetLink: https://container.googleapis.com/v1/projects/.../kubernetes-engine/docs/zones/us-central1-a/clusters/...
zone: us-central1-a

アップグレードがキャンセルされるか失敗し、部分的に完了している場合は、アップグレードを再開するかロールバックできます。

ノードプールのアップグレード設定を確認する

ノードプールで使用されているノードのアップグレード戦略の詳細を確認するには、gcloud container node-pools describe コマンドを使用します。Blue/Green アップグレードの場合、このコマンドによりアップグレードの現在のフェーズも返されます。

次のコマンドを実行します。

gcloud container node-pools describe NODE_POOL_NAME \
--cluster=CLUSTER_NAME

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

NODE_POOL_NAME: 記述するノードプールの名前。
CLUSTER_NAME: 記述するノードプールのクラスタの名前。

このコマンドにより、現在のアップグレード設定が出力されます。次の例は、Blue/Green アップグレード戦略を使用している場合の出力を示しています。

upgradeSettings:
  blueGreenSettings:
    nodePoolSoakDuration: 1800s
    standardRolloutPolicy:
      batchNodeCount: 1
      batchSoakDuration: 10s
  strategy: BLUE_GREEN

Blue/Green アップグレード戦略を使用している場合、出力には Blue/Green アップグレードの設定と現在の中間フェーズの詳細も含まれます。たとえば次のように表示されます。

updateInfo:
  blueGreenInfo:
    blueInstanceGroupUrls:
    - https://www.googleapis.com/compute/v1/projects/{PROJECT_ID}/zones/{LOCATION}/instanceGroupManagers/{BLUE_INSTANCE_GROUP_NAME}
    bluePoolDeletionStartTime: {BLUE_POOL_DELETION_TIME}
    greenInstanceGroupUrls:
    - https://www.googleapis.com/compute/v1/projects/{PROJECT_ID}/zones/{LOCATION}/instanceGroupManagers/{GREEN_INSTANCE_GROUP_NAME} 
    greenPoolVersion: {GREEN_POOL_VERSION}
    phase: DRAINING_BLUE_POOL

ノードプールのアップグレードをキャンセルする

アップグレードはいつでもキャンセルできます。サージアップグレードをキャンセルした場合の影響については、サージアップグレードをキャンセルするをご覧ください。 Blue/Green アップグレードをキャンセルした場合の影響については、Blue/Green アップグレードをキャンセルするをご覧ください。

アップグレードのオペレーション ID を取得します。
```
gcloud container operations list
```

アップグレードをキャンセルします。

gcloud container operations cancel OPERATION_ID

詳しくは、gcloud container operations cancel のドキュメントをご覧ください。

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

アップグレードを手動で開始することで、アップグレードを再開できます。その場合も、元のアップグレードのターゲットバージョンを指定します。

たとえば、アップグレードが失敗した場合や、進行中のアップグレードを一時停止した場合は、最初のアップグレードオペレーションのターゲットバージョンを指定して、ノードプールで同じアップグレードを再度開始することで、キャンセルしたアップグレードを再開できます。

アップグレードを再開した場合の影響については、サージアップグレードを再開すると Blue/Green アップグレードを再開するをご覧ください。

アップグレードを再開するには、次のコマンドを使用します。

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

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

NODE_POOL_NAME: ノードプールのアップグレードを再開するノードプールの名前。
CLUSTER_NAME: アップグレードを再開するノードプールのクラスタの名前。
VERSION: キャンセルされたノードプールのアップグレードのターゲットバージョン。

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

ノードプールのアップグレードのロールバック

ノードプールをロールバックして、アップグレードしたノードをノードプールのアップグレードを開始する前の元の状態にダウングレードできます。

進行中のアップグレードがキャンセルされた場合、アップグレードが失敗した場合、またはメンテナンスの時間枠のタイムアウトが原因でアップグレードが完了していない場合は、rollback コマンドを使用します。バージョンを指定する場合は、手順に沿ってノードプールをダウングレードします。

ノードプールのアップグレードをロールバックした場合の影響については、サージアップグレードをロールバックするまたは Blue/Green アップグレードをロールバックするをご覧ください。

アップグレードをロールバックするには、次のコマンドを実行します。

gcloud container node-pools rollback NODE_POOL_NAME \
  --cluster CLUSTER_NAME

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

NODE_POOL_NAME: ノードプールのアップグレードをロールバックするノードプールの名前。
CLUSTER_NAME: アップグレードをロールバックするノードプールのクラスタの名前。

詳しくは、gcloud container node-pools rollback のドキュメントをご覧ください。

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

Blue/Green アップグレード戦略を使用している場合は、ソークフェーズ中にノードプールのアップグレードが完了すると、残りのソーク時間をスキップできます。

ノードプールのアップグレードを完了する方法については、ノードプールのアップグレードを完了するをご覧ください。

Blue/Green アップグレード戦略を使用している場合にアップグレードを完了するには、次のコマンドを実行します。

gcloud container node-pools complete-upgrade NODE_POOL_NAME \
  --cluster CLUSTER_NAME

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

NODE_POOL_NAME: アップグレードを完了するノードプールの名前。
CLUSTER_NAME: アップグレードを完了するノードプールのクラスタの名前。

詳しくは、gcloud container node-pools complete-upgrade のドキュメントをご覧ください。

既知の問題

追加の中断を許可できない PodDisruptionBudget オブジェクトが構成されている場合、ノードのアップグレードを繰り返し試行しても、コントロールプレーンバージョンへのアップグレードが失敗する可能性があります。このエラーを回避するには、Deployment または HorizontalPodAutoscaler をスケールアップして、PodDisruptionBudget 構成を維持しながらノードをドレインすることをおすすめします。

中断を許可しないすべての PodDisruptionBudget オブジェクトを表示するには、次を行います。

kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'

自動アップグレードで問題が発生する可能性がありますが、自動アップグレードプロセスではノードのアップグレードを強制的に行います。ただし、アップグレードは istio-system Namespace のノードが PodDisruptionBudget に違反するたびに 1 時間余分にかかります。

トラブルシューティング

ノードプールのアップグレードが不完全で一部のノードのバージョンがノードプールのバージョンと一致していない

ノードプールのアップグレードオペレーションが完了しない理由としては、次のいずれかが考えられます。

ユーザーまたは GKE によってアップグレードがキャンセルされた。
予期しない問題が発生したため、アップグレードに失敗した。
メンテナンスの時間枠のタイムアウト、またはアップグレードを妨げるメンテナンスの除外が原因で、アップグレードが完了していない。

オペレーションが終了した場合、ノードプールのアップグレードステータスを確認することで、ノードプールのアップグレードオペレーションのステータスを確認できます。

ノードプールのアップグレードが部分的に完了している場合、次のようになっている可能性があります。

一部のノードのバージョンがノードプールのバージョンと一致していない。
ノードプールのバージョンが既存のバージョンになっている場合と新しいバージョンになっている場合がある。

ノードプールをすべてのノードで同じバージョンを実行している状態に戻すには、未完了のノードプールのアップグレードを再開またはロールバックします。

未完了のノードプールのアップグレードを再開またはロールバックする

GKE がノードプールのアップグレードを完了しておらず、ノードが新しいバージョンに部分的にアップグレードされている場合は、アップグレードを再開するか、ロールバックできます。これは、ノードのアップグレード戦略（サージアップグレードまたは Blue/Green アップグレード）のいずれかを使用するノードプールのアップグレードに関連しています。

手順に沿ってアップグレードを再開またはロールバックし、ノードプール内のすべてのノードが一貫したバージョンを実行するようにします。何もしない場合、GKE は最終的に、メンテナンスが利用可能なときにノードプールのアップグレードを再試行します。

ノードの CPU 使用率が予想より高い

一部の Pod の CPU 使用率が、実行中の Pod の予想値を上回ることがあります。

これは、クラスタまたはノードがサポートされているバージョンを実行していない場合に発生します。リリースノートで、使用しているバージョンが利用可能であり、サポートされていることを確認してください。次のコマンドを実行して、サポート対象のすべてのクラスタとノードのバージョンを一覧取得することもできます。

gcloud container get-server-config

次のステップ

クラスタアーキテクチャについて学習する。
リリースチャンネルについて学習する。

クラスタまたはノードプールの手動アップグレード コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

始める前に

データを永続ディスクに保存する

アップグレードについて

制限事項

サポート対象のバージョン

ダウングレードの制限事項

クラスタのアップグレード

コントロール プレーンの手動アップグレード

gcloud

コンソール

クラスタのダウングレード

クラスタの自動アップグレードの無効化

最近のコントロール プレーンのアップグレード履歴を確認する

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

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

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

gcloud

コンソール

ノードプールのダウングレード

サージ アップグレード パラメータを変更する

ノードプールのアップグレード ステータスを確認する

ノードプールのアップグレード設定を確認する

ノードプールのアップグレードをキャンセルする

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

ノードプールのアップグレードのロールバック

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

既知の問題

トラブルシューティング

ノードプールのアップグレードが不完全で一部のノードのバージョンがノードプールのバージョンと一致していない

未完了のノードプールのアップグレードを再開またはロールバックする

ノードの CPU 使用率が予想より高い

次のステップ

クラスタまたはノードプールの手動アップグレード

コントロールプレーンの手動アップグレード

最近のコントロールプレーンのアップグレード履歴を確認する

サージアップグレードパラメータを変更する

ノードプールのアップグレードステータスを確認する