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

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

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

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

始める前に

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

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

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

gcloud init の使用

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

  1. gcloud init を実行して、次の操作を行います。

    gcloud init

    リモート サーバーで SSH を使用している場合は、--console-only フラグを指定して、コマンドがブラウザを起動しないようにします。

    gcloud init --console-only
  2. 手順に従って gcloud を承認し、Google Cloud アカウントを使用します。
  3. 新しい構成を作成するか、既存の構成を選択します。
  4. Google Cloud プロジェクトを選択します。
  5. ゾーンクラスタの場合はデフォルトの Compute Engine ゾーン、リージョン クラスタまたは Autopilot クラスタの場合はデフォルトの Compute Engine リージョンを選択します。

gcloud config の使用

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

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

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

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

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

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

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

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

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

制限事項

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

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

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

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

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

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

    Google Kubernetes Engine のメニューに移動

  2. 目的のクラスタ名をクリックします。

  3. [クラスタの基本] で、[バージョン] の横にある [ アップグレード可能] をクリックします。

  4. 目的のバージョンを選択し、[変更を保存] をクリックします。

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

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

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

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

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

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

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

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

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

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

アップグレードは、すべてのノードが再作成され、クラスタが目的の状態になったときにはじめて完了します。新しくアップグレードされたノードがコントロール プレーンに登録されると、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 を使用してノードプールをアップグレードするには、次の手順を行います。

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

    Google Kubernetes Engine のメニューに移動

  2. 編集するクラスタの横にある [ アクション] をクリックし、[ 編集] をクリックします。

  3. [クラスタの詳細] ページで [ノード] タブをクリックします。

  4. [ノードプール] セクションで、アップグレードするノードプールの名前をクリックします。

  5. [ 編集] をクリックします。

  6. [ノードのバージョン] で [変更] をクリックします。

  7. [ノードのバージョン] プルダウン リストから目的のバージョンを選択し、[変更] をクリックします。

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

ノードプールは、クラスタ バージョンより古いパッチ バージョンにダウングレードできます。

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

アップグレードのステータスは、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

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

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

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

  1. アップグレードのオペレーション ID を取得するには、次のコマンドを使用します。

    gcloud container operations list

  2. アップグレードをキャンセルするには、次のコマンドを実行します。

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

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

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

  • 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

次のステップ