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

デフォルトで、Google Kubernetes Engine クラスタとノードプールは Google によって自動的にアップグレードされます。このページでは、GKE クラスタまたはそのノードのアップグレードとダウングレードを手動で要求する方法について説明します。詳細については、自動および手動クラスタアップグレードの動作をご覧ください。メンテナンスの時間枠と除外対象を構成することで、自動アップグレードのタイミングを管理することもできます。

新しいバージョンの GKE は定期的に発表されています。利用可能なバージョンについては、バージョニングをご覧ください。クラスタの詳細については、クラスタのアーキテクチャをご覧ください。クラスタのアップグレードに関するガイドについては、クラスタのアップグレードに関するベストプラクティスをご覧ください。

始める前に

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

Google Kubernetes Engine API が有効になっていることを確認します。

Google Kubernetes Engine API の有効化

Cloud SDK がインストール済みであることを確認します。

次のいずれかの方法で gcloud のデフォルトの設定を指定します。

gcloud init。デフォルトの設定全般を確認する場合に使用します。
gcloud config。プロジェクト ID、ゾーン、リージョンを個別に設定する場合に使用します。

gcloud init の使用

エラー One of [--zone, --region] must be supplied: Please specify location を受信した場合は、このセクションの内容を実施します。

gcloud init を実行して、次の操作を行います。
```
gcloud init
```
リモートサーバーで SSH を使用している場合は、--console-only フラグを指定して、コマンドがブラウザを起動しないようにします。
```
gcloud init --console-only
```
手順に従って gcloud を承認し、Google Cloud アカウントを使用します。
新しい構成を作成するか、既存の構成を選択します。
Google Cloud プロジェクトを選択します。
デフォルトの Compute Engine ゾーンを選択します。

注: これらのデフォルト設定は、gcloud コマンドで --project、--zone、--region フラグを使用することでオーバーライドできます。

gcloud config の使用

デフォルトのプロジェクト ID を設定します。
```
gcloud config set project PROJECT_ID
```
ゾーンクラスタを使用する場合は、デフォルトのコンピューティングゾーンを設定します。
```
gcloud config set compute/zone COMPUTE_ZONE
```
リージョンクラスタを使用する場合は、デフォルトのコンピューティングリージョンを設定します。
```
gcloud config set compute/region COMPUTE_REGION
```
gcloud を最新バージョンに更新します。
```
gcloud components update
```

注: これらのデフォルト設定は、gcloud コマンドで --project、--zone、--region フラグを使用することでオーバーライドできます。

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

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

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

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

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

クラスタのアップグレードについて

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

制限事項

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

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

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

gcloud container get-server-config

既知の問題

Anthos Service Mesh または OSS Istio をクラスタにインストールしている場合、Istio コンポーネントの PodDisruptionBudget 設定方法によっては、再試行してもユーザーノードによるコントロールプレーンバージョンへのアップグレードが失敗する可能性があります。このエラーを回避するには、アップグレードをする前に、istio-system 名前空間のコンポーネントで水平ポッド自動スケーリングの minReplicas 設定を 1 から 2 に増やすことをおすすめします。これにより、ASM コントロールプレーンのインスタンスが常に実行されます。

Anthos Service Mesh 1.5 以降または OSS Istio 1.5 以降を使用している場合:

kubectl patch hpa -n istio-system istio-ingressgateway -p '{"spec":{"minReplicas": 2}}' --type=merge

kubectl patch hpa -n istio-system istiod -p '{"spec":{"minReplicas": 2}}' --type=merge

Anthos Service Mesh 1.4.x または OSS Istio 1.4.x を使用している場合:

kubectl patch hpa -n istio-system istio-galley -p '{"spec":{"minReplicas": 2}}' --type=merge

kubectl patch hpa -n istio-system istio-ingressgateway -p '{"spec":{"minReplicas": 2}}' --type=merge

kubectl patch hpa -n istio-system istio-nodeagent -p '{"spec":{"minReplicas": 2}}' --type=merge

kubectl patch hpa -n istio-system istio-pilot -p '{"spec":{"minReplicas": 2}}' --type=merge

kubectl patch hpa -n istio-system istio-sidecar-injector -p '{"spec":{"minReplicas": 2}}' --type=merge

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

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

クラスタをダウングレードすることはおすすめしません。ノードは、クラスタバージョンより古いパッチバージョンにダウングレードできます。クラスタをマイナーバージョン間でダウングレードすることはできません。たとえば、クラスタで GKE 1.11.5 を実行している場合、まだ利用可能であれば 1.11.4 にダウングレードできますが、1.10.9 にはダウングレードできません。次のようなエラーが生成されます。

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

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

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

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

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

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

クラスタのアップグレードを開始すると、コントロールプレーンに再びアクセスできるまで、数分間はクラスタの構成を変更できません。コントロールプレーンのアップグレード中のダウンタイムを防ぐ必要がある場合は、リージョンクラスタの使用を検討してください。

クラスタを手動でアップグレードするには、Cloud Console を使用するか、gcloud コマンドラインツールを使用します。クラスタをアップグレードした後、そのノードをアップグレードできます。デフォルトでは、Google Cloud Console で作成したノードでは自動アップグレードが有効になります。このため、アップグレードは自動的に行われます。

gcloud

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

gcloud container get-server-config

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

gcloud container clusters upgrade CLUSTER_NAME --master

デフォルト以外の特定のバージョンにアップグレードするには、次のコマンドを実行します。

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

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

Console

クラスタコントロールプレーンを手動で更新するには、次の手順に従います。

Google Cloud Console で Google Kubernetes Engine のメニューに移動します。

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

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

クラスタを以前のパッチバージョンにダウングレードするには、次のコマンドを使用してクラスタコントロールプレーンバージョンを変更します。

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

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

クラスタの自動アップグレードは無効にできません。推奨ではありませんが、ノードの自動アップグレードは無効にできます。

ノードのアップグレード

デフォルトでは、クラスタのノードで自動アップグレードが有効になっています。無効にすることはおすすめしません。

ノードプールをアップグレードするときに、サージアップグレードの設定を構成して、GKE が一度にアップグレードするノードの数と、アップグレードがワークロードに与える影響の大きさを制御できます。デフォルトでは、GKE は一度に 1 ノードずつアップグレードします。

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

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

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

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

手動でアップグレードできるノードプールのバージョンは、コントロールプレーンと同じバージョンか、引き続き使用可能でコントロールプレーンと互換性のある以前のバージョンです。Kubernetes バージョンとバージョンスキューのサポートポリシーにより、コントロールプレーンは、コントロールプレーンの 2 つ前までのマイナーバージョンのノードと互換性が保証されています。たとえば、Kubernetes 1.13 コントロールプレーンは Kubernetes 1.11 ノードと互換性があります。

コントロールプレーンと互換性のあるバージョンを手動でアップグレードするには、Google Cloud Console または gcloud コマンドラインツールを使用します。

gcloud

次のコマンドは、ノードをコントロールプレーンで実行されているバージョンにアップグレードします。

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

CLUSTER_NAME は、アップグレードするクラスタの名前に置き換えます。

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

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

VERSION は、ノードのアップグレード先の Kubernetes バージョンに置き換えます。たとえば、--cluster-version=1.7.2 や cluster-version=latest です。

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

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

Console

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

Cloud Console で Google Kubernetes Engine のメニューに移動します。

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

ノードのダウングレード

ノードプールをダウングレードすることはできません。その代わりに、目的のバージョンで新しいノードプールを作成して、ワークロードを移行します。自動アップグレードが有効になっているノードは、コントロールプレーンのバージョンに合わせてアップグレードされます。

ノードのアップグレードステータスの確認

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

クラスタ内の実行中のオペレーションと完了したオペレーションの全リストを表示するには、次のコマンドを実行します。

gcloud beta 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 beta container operations describe OPERATION_ID

例:

gcloud beta 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

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

アップグレードはいつでもキャンセルできます。アップグレードをキャンセルすると、次のようになります。

アップグレードを開始したノードのアップグレードは完了します。
アップグレードを開始していないノードはアップグレードされません。
アップグレードがすでに完了したノードは影響を受けず、ロールバックされません。

アップグレードのオペレーション ID を取得するには、次のコマンドを使用します。
```
gcloud container operations list
```
アップグレードをキャンセルするには、次のコマンドを実行します。
```
gcloud beta container operations cancel OPERATION_ID
```

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

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

アップグレードに失敗したノードプールまたはアップグレードがキャンセルされたノードプールを以前のバージョンの Kubernetes にロールバックできます。正常にアップグレードされたノードプールをロールバックすることはできません。アップグレードを開始していないノードは影響を受けません。

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

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

以下を置き換えます。

NODE_POOL_NAME: ロールバックするノードプールの名前。
CLUSTER_NAME: ノードプールのロールバック元となるクラスタの名前。

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

サージアップグレードパラメータの変更

サージアップグレードを使用すると、GKE が一度にアップグレードするノード数とアップグレードでワークロードが中断される回数を変更できます。

max-surge-upgrade フラグと max-unavailable-upgrade フラグは、ノードプールごとに定義されています。適切なパラメータの選択について詳しくは、最適なサージ構成の決定をご覧ください。

注: すべての新しいノードプールは、サージアップグレード（maxSurge=1 maxUnavailable=0）を使用するように自動的に構成されます。構成を調整するには、最適なサージ構成の決定をご覧ください。

これらの設定は、クラスタやノードプールを作成または更新するときに変更できます。

下記のコマンドでは、次の変数を使用しています。

CLUSTER_NAME: ノードプールのクラスタの名前。
COMPUTE_ZONE: クラスタのゾーン。
NODE_POOL_NAME: ノードプールの名前。
NUMBER_NODES: 各クラスタのゾーンにあるノードプール内のノード数。
SURGE_NODES: ノードプールのアップグレードのたびに作成される余分な（サージ）ノードの数。
UNAVAILABLE_NODES: ノードプールの各アップグレードで同時に使用不可になるノードの数。

特定のパラメータでクラスタを作成する

サージアップグレードに固有の設定でクラスタを作成するには、max-surge-upgrade フラグと max-unavailable-upgrade フラグを使用します。

gcloud container clusters create CLUSTER_NAME \
  --max-surge-upgrade=SURGE_NODES --max-unavailable-upgrade=UNAVAILABLE_NODES

サージアップグレードが無効なクラスタを作成する

サージアップグレードなしでクラスタを作成するには、max-surge-upgrade フラグの値を 0 に設定します。

gcloud container clusters create CLUSTER_NAME \
  --max-surge-upgrade=0 --max-unavailable-upgrade=1

特定のサージパラメータでノードプールを作成する

サージアップグレードに固有の設定で既存のクラスタにノードプールを作成するには、max-surge-upgrade フラグと max-unavailable-upgrade フラグを使用します。

gcloud container node-pools create NODE_POOL_NAME \
  --num-nodes=NUMBER_NODES --cluster=CLUSTER_NAME \
  --max-surge-upgrade=SURGE_NODES --max-unavailable-upgrade=UNAVAILABLE_NODES

既存のノードプールのサージアップグレードをオンまたはオフにする

既存のノードプールのアップグレード設定を更新するには、max-surge-upgrade フラグと max-unavailable-upgrade フラグを使用します。max-surge-upgrade を 0 よりも大きい値に設定すると、GKE によってサージノードが作成されます。max-surge-upgrade を 0 に設定すると、サージノードは作成されません。

gcloud beta container node-pools update NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --max-surge-upgrade=SURGE_NODES --max-unavailable-upgrade=UNAVAILABLE_NODES

ノードプールでサージアップグレードが有効になっていることを確認する

ノードプールでサージアップグレードが有効になっていることを確認するには、gcloud を使用してクラスタのパラメータを表示します。

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

次のステップ

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

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

始める前に

gcloud init の使用

gcloud config の使用

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

クラスタのアップグレードについて

制限事項

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

既知の問題

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

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

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

gcloud

Console

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

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

ノードのアップグレード

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

gcloud

Console

ノードのダウングレード

ノードのアップグレード ステータスの確認

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

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

サージ アップグレード パラメータの変更

特定のパラメータでクラスタを作成する

サージ アップグレードが無効なクラスタを作成する

特定のサージ パラメータでノードプールを作成する

既存のノードプールのサージ アップグレードをオンまたはオフにする

ノードプールでサージ アップグレードが有効になっていることを確認する

次のステップ

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

ノードのアップグレードステータスの確認

サージアップグレードパラメータの変更

サージアップグレードが無効なクラスタを作成する

特定のサージパラメータでノードプールを作成する

既存のノードプールのサージアップグレードをオンまたはオフにする

ノードプールでサージアップグレードが有効になっていることを確認する