Anthos clusters on VMware のアップグレード

Version 1.13 

• Version 1.15 (latest)
• Version 1.14
• Version 1.13
• Version 1.12 (unsupported)
• Version 1.11 (unsupported)
• Version 1.10 (unsupported)
• Earlier versions (unsupported)

このページでは、Anthos clusters on VMware（GKE On-Prem）をアップグレードする方法について説明します。

アップグレード プロセスの概要

注: アップグレードの準備に進む前に、互換性マトリックスをチェックして、システムがアップグレードの要件を満たしていることを確認してください。

同じマイナー リリースか、その次のマイナー リリースに含まれるバージョンに直接アップグレードできます。たとえば、1.13.0 から 1.13.1、または 1.12.1 から 1.13.0 にアップグレードできます。

1 つ上のマイナー リリースの一部ではないバージョンにアップグレードする場合は、現在のバージョンと目的のバージョンの間の各マイナー バージョンを経由してアップグレードする必要があります。たとえば、バージョン 1.11.2 からバージョン 1.13.0 にアップグレードする場合、直接アップグレードすることはできません。まず、バージョン 1.11.2 からバージョン 1.12.x にアップグレードし、続いてバージョン 1.13.0 にアップグレードする必要があります。

このトピックでは、バージョン 1.12.x からバージョン 1.13.y にアップグレードする方法について説明します。

アップグレード プロセスを開始する前に、クラスタのアップグレードに関するベスト プラクティスを確認してください。

アップグレードの全体的なワークフローは次のとおりです。

1. 管理ワークステーションをアップグレードのターゲット バージョンにアップグレードします。

2. 管理ワークステーションから、ユーザー クラスタをアップグレードします。

3. すべてのユーザー クラスタをアップグレードすると、管理ワークステーションから管理クラスタをアップグレードできます。アップグレードで利用できる機能が必要な場合以外は、この手順を省略できます。

   注: バージョン 1.13.0 以降にアップグレードする場合は、クラスタを登録した後にのみ管理クラスタをアップグレードできます。詳細については、管理クラスタの登録をご覧ください。

非同期ユーザー クラスタのアップグレード

ユーザー クラスタをアップグレードする場合、gkectl upgrade cluster コマンドには 2 つのバリエーションがあります。

• 非同期（推奨）
• 同期

非同期のバリエーションでは、コマンドによってアップグレードが開始され、完了します。アップグレード期間中は、コマンドの出力を監視する必要はありません。代わりに、gkectl list cluster と gkectl describe cluster を実行して、アップグレードの進行状況を定期的に確認できます。

非同期バリエーションを使用するには、コマンドに --async フラグを含めます。詳細については、ユーザー クラスタのアップグレードをご覧ください。

アップグレードを準備する

管理ワークステーションを作成する前に、gkeadm create config によって生成された管理ワークステーションの構成ファイルに入力しました。このファイルのデフォルト名は admin-ws-config.yaml です。

また、ワークステーションにも情報ファイルがあります。このファイルのデフォルト名は、管理ワークステーションの名前と同じです。

管理ワークステーションの構成ファイルと情報ファイルを探します。アップグレード手順を実行するには、それらが必要です。これらのファイルが現在のディレクトリにあり、デフォルトの名前が使われている場合は、アップグレード コマンドを実行するときに名前を指定する必要はありません。これらのファイルが別のディレクトリにある場合や、ファイル名を変更した場合は、--config フラグと --info-file フラグを使用して指定します。

出力情報ファイルがない場合は、再作成できます。情報ファイルがない場合は再作成するをご覧ください。

管理ワークステーションをアップグレードする

1. gkeadm をダウンロードする

   gkeadm upgrade gkeadm --target-version TARGET_VERSION
   

   TARGET_VERSION は、アップグレードのターゲット バージョンに置き換えます。

2. 管理ワークステーションをアップグレードする

   gkeadm upgrade admin-workstation --config AW_CONFIG_FILE --info-file INFO_FILE
   

   以下を置き換えます。

   • AW_CONFIG_FILE: 管理ワークステーションの構成ファイルのパス。ファイルが現在のディレクトリにあり、名前が admin-ws-config.yaml の場合、このフラグを省略できます。

   • INFO_FILE: 情報ファイルのパス。ファイルが現在のディレクトリにある場合は、このフラグを省略できます。このファイルのデフォルト名は、管理ワークステーションの名前と同じです。

上記のコマンドによって、以下のタスクが実行されます。

• 現在の管理ワークステーションのホーム ディレクトリにあるすべてのファイルをバックアップします。たとえば、次のようなものが挙げられます。

  • 管理クラスタの構成ファイル。デフォルト名は admin-cluster.yaml です。
  • ユーザー クラスタの構成ファイル。デフォルト名は user-cluster.yaml です。
  • 管理クラスタとユーザー クラスタの kubeconfig ファイル
  • vCenter サーバーのルート証明書（このファイルにはオーナーの読み取り権限とオーナーの書き込み権限が必要）。
  • コンポーネント アクセス サービス アカウントの JSON キーファイル（このファイルにはオーナーの読み取り権限とオーナーの書き込み権限が必要）。
  • connect-register、logging-monitoring サービス アカウントの JSON キーファイル。

• 新しい管理ワークステーションを作成し、すべてのバックアップ ファイルを新しい管理ワークステーションにコピーします。

• 古い管理ワークステーションを削除します。

注: 管理ワークステーションをアップグレードすると、gkeadm はバックアップ ファイルを保存します。必要に応じて、バックアップ ファイルから管理ワークステーションを復元できます。

十分な IP アドレスが使用可能であることを確認する

クラスタをアップグレードする前に、十分な数の IP アドレスが割り振られているようにしてください。必要に応じて、追加の IP アドレスを割り振ることができます。必要な IP アドレスの数を決定するには、ノード IP アドレスの管理をご覧ください。

ユーザー クラスタをアップグレードする

コマンドライン

コマンドラインで実施できるユーザー クラスタのアップグレードには、次の 2 種類があります。

• 非同期
• 同期

非同期アップグレード

gkectl prepare を実行して、OS イメージを vSphere にインポートします。

gkectl prepare \
  --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG

ユーザー クラスタの構成ファイルで、gkeOnPremVersion をアップグレードのターゲット バージョンに設定します。

管理ワークステーションで、非同期アップグレードを開始します。

gkectl upgrade cluster \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG \
  --async

上記のコマンドは完了しており、アップグレードの進行中も、ユーザー クラスタを引き続き使用できます。

アップグレードのステータスを確認するには:

gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG

出力に、クラスタ STATE の値が表示されます。クラスタがまだアップグレード中の場合、STATE の値は UPGRADING になります。次に例を示します。

NAMESPACE             NAME    READY   STATE       AGE   VERSION
my-uc-gkeonprem-mgmt  my-uc   False   UPGRADING   9h    1.13.0-gke.1

STATE の想定される値は、PROVISIONING、UPGRADING、DELETING、UPDATING、RUNNING、RECONCILING、ERROR、UNKNOWN です。

アップグレードの進行状況とクラスタ イベントの詳細を確認するには:

gkectl describe cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --cluster USER_CLUSTER_NAME -v 5

出力には、クラスタ ステータス、条件、イベントを含む、指定したユーザー クラスタの OnPremUserCluster カスタム リソースが表示されます。

Google では、次のような重要なアップグレード フェーズの開始時と終了時のイベントを記録します。

• ControlPlaneUpgrade
• MasterNodeUpgrade
• AddonsUpgrade
• NodePoolsUpgrade

出力例:

Events:
Type    Reason                      Age    From                            Message
----     ------                     ----   ----                            -------
Normal  NodePoolsUpgradeStarted     22m    onprem-user-cluster-controller  Creating or updating node pools: pool-2: Creating or updating node pool
Normal  AddonsUpgradeStarted        22m    onprem-user-cluster-controller  Creating or updating addon workloads
Normal  ControlPlaneUpgradeStarted  25m    onprem-user-cluster-controller  Creating or updating cluster control plane workloads: deploying user-kube-apiserver-base, ...: 14/15 pods are ready
Normal  ControlPlaneUpgradeFinished 23m    onprem-user-cluster-controller  Control plane is running

アップグレードが完了すると、gkectl list cluster に STATUS が RUNNING と表示されます。

NAMESPACE             NAME    READY   STATE     AGE     VERSION
my-uc-gkeonprem-mgmt  my-uc   True    RUNNING   9h      1.13.0-gke.1

また、アップグレードが完了すると、gkectl describe cluster に Status の下に LastGKEOnPremVersion フィールドが表示されます。次に例を示します。

Status:
Cluster State:  RUNNING
LastGKEOnOremVersion:  1.12.0-gke.0

非同期アップグレードのトラブルシューティング

非同期アップグレードの場合、タイムアウト時間はクラスタ内のノード数に基づきます。アップグレードがタイムアウト時間よりも長くかかる場合、アップグレード オペレーションがタイムアウトしたことを示すイベントが発生し、クラスタの状態が UPGRADING から ERROR に変更されます。ここでの ERROR 状態は、アップグレードに想定以上の時間がかかる一方、アップグレードは終了していないことを意味します。コントローラは調整を続行し、オペレーションを再試行します。

通常、タイムアウトは PodDisruptionBudget（PDB）によって発生したデッドロックの結果です。その場合、Pod は古いノードから強制排除されず、古いノードはドレインできません。Pod の強制排除に 10 分以上かかる場合は、OnPremUserCluster オブジェクトにイベントを書き込みます。イベントをキャプチャするには、gkectl describe cluster を実行します。その後、PDB を調整してノードがドレインされるようにします。その後はアップグレードを続行でき、最終的に完了します。

イベントの例:

Warning  PodEvictionTooLong  96s (x2 over 4m7s)  onprem-user-cluster-controller
Waiting too long(>10m0.00000003s) for (kube-system/coredns-856d6dbfdf-dl6nz) eviction.

また、アップグレードがブロックされているか失敗した場合は、gkectl diagnose を実行してクラスタの一般的な問題を確認できます。その結果に基づいて、手動修正を実行するか、Anthos サポートチームにお問い合わせください。

同期アップグレード

gkectl upgrade コマンドは、プリフライト チェックを実行します。プリフライト チェックが不合格の場合、コマンドはブロックされます。エラーを修正するか、--skip-preflight-check-blocking フラグを使用する必要があります。重大な不備がないことが確実な場合にのみ、プリフライト チェックをスキップしてください。

管理ワークステーションで次の手順を行います。

1. gkectl prepare を実行して、OS イメージを vSphere にインポートします。

   gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
   

2. ユーザー クラスタの構成ファイルで、gkeOnPremVersion をアップグレードのターゲット バージョンに設定します。

3. クラスタをアップグレードします。

   gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
   

Google Cloud コンソール

1. 管理ワークステーションで、次のコマンドを実行します。

   gkectl prepare \
       --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --upgrade-platform
   

   以下を置き換えます。

   • ADMIN_CLUSTER_KUBECONFIG は、管理クラスタの kubeconfig ファイルのパスです。

   このコマンドは、ユーザー クラスタ コントローラとロールベースのアクセス制御（RBAC）ポリシーをアップグレードし、Google Cloud コンソールでユーザー クラスタを管理できるようにします。

2. Google Cloud コンソールで、Anthos の [クラスタ] ページに移動します。

   [Anthos クラスタ] ページに移動

3. ユーザー クラスタが存在するクラウド プロジェクトを選択します。

4. クラスタのリストで、アップグレードするクラスタをクリックします。

5. [詳細] パネルで、[タイプ] が [vm Anthos (VMware)] の場合、次の手順に沿って Google Cloud コンソールでクラスタをアップグレードします。

   1. [詳細] パネルで、[詳細] をクリックします。

   2. [クラスタの基本] セクションで、 アップグレードをクリックします。

   3. [Anthos clusters on VMware のバージョン] リストで、アップグレードするバージョンを選択します。

   4. [アップグレード] をクリックします。

   [種類] が [外部] の場合は、クラスタが gkectl を使用して作成されたことを示します。この場合は、[コマンドライン] タブの手順に沿ってクラスタをアップグレードします。

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

ユーザー クラスタのアップグレードが中断された場合は、--skip-validation-all フラグを指定して同じアップグレード コマンドを使用すると、ユーザー クラスタのアップグレードを再開できます。

gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE \
    --skip-validation-all

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

開始する前に:

• 証明書が最新かどうかを確認し、必要に応じて更新します。

• バージョン 1.13 以降にアップグレードする場合は、まず管理クラスタの構成ファイルに gkeConnect セクションを入力して、管理クラスタを登録する必要があります。構成ファイルを変更して、update コマンドを実行します。

新しい管理ワークステーションで、このセクションの手順を行います。gkectl とクラスタがアップグレードに合ったバージョンになっており、適切なバンドルがダウンロードされていることを確認します。

注: gkectl のバージョンは、目的のアップグレード バージョン以降でなければなりません。たとえば、gkectl のバージョンが 1.12.0 の場合は、クラスタを 1.12.0 または 1.11.x にアップグレードできます。管理クラスタは、すべてのユーザー クラスタが、同じマイナー バージョンまでアップグレードされた場合にのみ、そのマイナー バージョンにアップグレードできます。

1. 管理クラスタ構成ファイルの bundlepath フィールドが、アップグレード先のバンドルのパスと一致していることを確認します。

   管理クラスタ構成ファイルのフィールドで他の変更を行っている場合、その変更はアップグレード時に無視されます。そうした変更を有効にするには、まずクラスタをアップグレードした後、構成ファイルを変更して更新コマンドを実行することで、他の変更をクラスタに施す必要があります。

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

   gkectl upgrade admin \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --config ADMIN_CLUSTER_CONFIG_FILE \
       FLAGS
   

   以下を置き換えます。

   • ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイル。

   • ADMIN_CLUSTER_CONFIG_FILE: 新しい管理ワークステーション上の Anthos clusters on VMware 管理クラスタの構成ファイル。

   • FLAGS: オプションの一連のフラグ。たとえば、vSphere インフラストラクチャのチェックをスキップする --skip-validation-infra フラグを指定できます。

注: gkectl upgrade コマンドは、プリフライト チェックを実行します。プリフライト チェックが不合格の場合、コマンドはブロックされます。不備を修正するか、このコマンドでフラグ --skip-preflight-check-blocking を使用してブロックを解除する必要があります。

フルバンドルをダウンロードした後、gkectl prepare コマンドと gkectl upgrade admin コマンドが正常に実行されたら、管理ワークステーションのディスク スペースを節約するために、フルバンドルを削除する必要があります。次のコマンドを使用します。

rm /var/lib/gke/bundles/gke-onprem-vsphere-${TARGET_VERSION}-full.tgz

管理クラスタのアップグレードを再開する

管理クラスタのアップグレードが中断または失敗した場合で、管理クラスタのチェックポイントに、中断前の状態を復元するために必要な状態が含まれている場合は、アップグレードを再開できます。

警告: アップグレードの失敗後は、gkectl repair admin-master で管理マスターを修復しないでください。これを行うと、管理クラスタが不正な状態になります。

手順は次のとおりです。

1. 最初のアップグレードの実施を始める前に、管理コントロール プレーンが正常かどうかを確認します。クラスタの問題を診断するをご覧ください。そのトピックで説明されているように、管理クラスタに対して gkectl diagnose cluster コマンドを実行します。

2. 最初のアップグレード試行の前に、管理コントロール プレーンが正常でない場合は、gkectl repair admin-master コマンドで管理コントロール プレーンを修復します。

3. アップグレードが中断または失敗した後にアップグレード コマンドを再実行すると、以前のアップグレード試行と同じバンドルとターゲット バージョンが使用されます。

アップグレード コマンドを再実行すると、チェックポイントから管理クラスタの状態が再作成され、アップグレード全体が再実行されます。1.12.0 以降、管理コントロール プレーンが正常でない場合、アップグレード プロセスは、アップグレードに進む前にソース バージョンで管理クラスタを復元せず、直接ターゲット バージョンにアップグレードされます。

管理クラスタのチェックポイントが使用可能な場合、アップグレードは失敗した時点か、終了した時点から再開されます。チェックポイントが使用できない場合は、アップグレードが管理コントロール プレーンへの依存にフォールバックするため、アップグレードを進めるには管理コントロール プレーンが正常である必要があります。アップグレードが成功すると、チェックポイントは再生成されます。

管理クラスタのアップグレード中に gkectl が予期せず終了した場合、その種類のクラスタはクリーンアップされません。アップグレード コマンドを再実行してアップグレードを再開する前に、その種類のクラスタを削除します。

docker stop gkectl-control-plane && docker rm gkectl-control-plane

種類クラスタを削除したら、アップグレード コマンドを再度実行します。

アップグレード後に管理ワークステーションをロールバックする

管理ワークステーションは、アップグレード前に使用したバージョンにロールバックできます。

アップグレード中、gkeadm はアップグレード前のバージョンを出力情報ファイルに記録します。ロールバック中、gkeadm はリストされたバージョンを使用して古いファイルをダウンロードします。

管理ワークステーションを以前のバージョンにロールバックするには:

gkeadm rollback admin-workstation --config=AW_CONFIG_FILE

管理ワークステーション構成ファイルがデフォルトの admin-ws-config.yaml の場合は、--config=AW_CONFIG_FILE を省略できます。それ以外の場合は、AW_CONFIG_FILE を管理ワークステーションの構成ファイルのパスに置き換えます。

rollback コマンドは、次の手順を実行します。

1. gkeadm のロールバック バージョンをダウンロードします。
2. 現在の管理ワークステーションのホーム ディレクトリをバックアップします。
3. gkeadm のロールバック バージョンを使用して、新しい管理ワークステーションを作成します。
4. 元の管理ワークステーションを削除します。

アップグレード用に別バージョンのバンドルをインストールする

ワークステーションをアップグレードすると、クラスタのアップグレード用に、対応するバージョンのバンドルがインストールされます。別のバージョンが必要な場合は、次の手順に沿って TARGET_VERSION のバンドルをインストールします。これはアップグレード後のバージョンです。

1. 現在の gkectl とクラスタのバージョンを確認するには、次のコマンドを実行します。詳細は、フラグ --details/-d を使用して確認してください。

   gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details
   

   出力には、クラスタのバージョンに関する情報が表示されます。

2. 取得した出力に基づいて、次の問題を確認し、必要に応じて修正します。

   • 現在の管理クラスタのバージョンが TARGET_VERSION よりマイナー バージョンで 1 バージョン超低い場合は、すべてのクラスタを TARGET_VERSION より 1 マイナー バージョン低いバージョンにアップグレードします。

   • gkectl バージョンが 1.11 未満で、1.12.x にアップグレードする場合は、アップグレードを複数回行う必要があります。1.11.x になるまではマイナー バージョンを 1 つずつアップグレードしてから、このトピックの手順に進んでください。

   • gkectl バージョンが TARGET_VERSION より新しいバージョンの場合は、TARGET_VERSION に管理ワークステーションをアップグレードします。

3. gkectl とクラスタ バージョンがアップグレードに適していると判断した場合は、バンドルをダウンロードします。

   バンドルの tarball が管理ワークステーションに存在するかどうかを確認します。

   stat /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz

   バンドルが管理ワークステーションにない場合は、ダウンロードします。

   gsutil cp gs://gke-on-prem-release/gke-onprem-bundle/TARGET_VERSION/gke-onprem-vsphere-TARGET_VERSION.tgz /var/lib/gke/bundles/
   

4. バンドルをインストールします。

   gkectl prepare --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz --kubeconfig ADMIN_CLUSTER_KUBECONFIG
   

   ADMIN_CLUSTER_KUBECONFIG は、kubeconfig ファイルのパスに置き換えます。ファイルが現在のディレクトリにあり、名前が kubeconfig の場合、このフラグを省略できます。

   注: デフォルトでは、完全なバンドルではなく標準バンドルがダウンロードされます。フルバンドルにはすべてのコンテナ イメージと VM イメージが含まれています。一方、標準バンドルでは、コンテナ イメージと VM イメージは、インストールするときに Google Cloud Platform から管理ワークステーションにダウンロードされます。標準バンドルではなく、完全なバンドルを使用するには、インストール コマンドでバンドルパスを gke-onprem-vsphere-TARGET_VERSION-full.tgz にします。

5. 使用可能なクラスタ バージョンを一覧表示し、使用可能なユーザー クラスタ バージョンにターゲット バージョンが含まれていることを確認します。

   gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

これで、ターゲット バージョンでユーザー クラスタを作成することや、ユーザー クラスタをターゲット バージョンにアップグレードすることが可能になります。

アップグレード プロセスのトラブルシューティング

推奨するアップグレード プロセスに従って問題が発生した場合は、次の手順で解決することをおすすめします。以下の推奨事項は、バージョン 1.11.x のセットアップをすでに開始しており、推奨のアップグレード プロセスを進めることを前提としています。

クラスタの作成とアップグレードに関するトラブルシューティングをご覧ください。

ユーザー クラスタのアップグレードに関する問題のトラブルシューティング

ユーザー クラスタのアップグレード時にアップグレード バージョンに問題があるとします。今後のパッチリリースで問題が解決することを Google サポートに確認します。次のように進めることができます。

1. 本番環境では、引き続き現在のバージョンを使用します。
2. リリース時には、非本番環境クラスタでパッチリリースをテストします。
3. 問題ないと判断できる場合は、すべての本番環境ユーザー クラスタをパッチリリース バージョンにアップグレードします。
4. 管理クラスタをパッチリリース バージョンにアップグレードします。

管理クラスタのアップグレードに関する問題のトラブルシューティング

管理クラスタのアップグレード中に問題が発生した場合は、Google サポートに連絡して管理クラスタの問題を解決する必要があります。

新しいアップグレード フローを使用すれば、管理クラスタのアップグレードでブロックされることなく、ユーザー クラスタの新機能を利用できます。これにより、必要に応じて管理クラスタのアップグレード頻度を減らすことができます。アップグレード プロセスは次のようになります。

1. 本番環境のユーザー クラスタを 1.12.x にアップグレードします。
2. 管理クラスタは以前のバージョンのままにして、セキュリティ パッチを引き続き受信します。
3. テスト環境で管理クラスタの 1.11.x から 1.12.x へのアップグレードをテストし、問題があれば報告します。
4. 1.12.x のパッチリリースで問題が解決した場合は、必要に応じて本番環境管理クラスタをこのパッチリリースにアップグレードすることも可能です。

最近のバージョンに関する既知の問題

バージョン 1.7 以降からアップグレードすると、以下の既知の問題がアップグレードに影響を及ぼすことがあります。

既知の問題もご覧ください。

データディスクの残り容量が僅かになると、管理ワークステーションのアップグレードが失敗することがある

gkectl upgrade admin-workstation コマンドを使用して管理ワークステーションをアップグレード場合、データディスクの残り容量が僅かになるとアップグレードが失敗することがあります。これは、新しい管理ワークステーションへのアップグレード中に、現在の管理ワークステーションのバックアップがローカルで試行されるためです。データディスクの空き容量を確保できない場合は、--backup-to-local=false フラグが追加された gkectl upgrade admin-workstation コマンドを使用して、現在の管理ワークステーションのバックアップがローカルで作成されないようにします。

PodDisruptionBudgets を使用するワークロードが中断する

現時点では、クラスタをアップグレードすると、PodDisruptionBudgets（PDB）を使用するワークロードで中断やダウンタイムが発生することがあります。

ノードがアップグレード プロセスを完了できない

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

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

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

付録

バージョン 1.1.0-gke.6 で有効になっている VMware DRS ルールについて

バージョン 1.1.0-gke.6 以降、Anthos clusters on VMware はユーザー クラスタのノードに対して VMware Distributed Resource Scheduler（DRS）の反アフィニティ ルールを自動的に作成し、データセンター内の少なくとも 3 つの物理ホストにそれらを分散させます。バージョン 1.1.0-gke.6 以降、この機能は新しいクラスタと既存のクラスタで自動的に有効になります。

アップグレードを行う前に、vSphere 環境が次の条件を満たしていることを確認してください。

• VMware DRS が有効になっていること。VMware DRS には、vSphere Enterprise Plus ライセンス エディションが必要です。DRS を有効にする方法については、クラスタ内の VMware DRS の有効化をご覧ください。

• 認証情報の構成ファイルで指定される vSphere ユーザー名には、Host.Inventory.EditCluster 権限があります。

• 利用可能な物理ホストが少なくとも 3 つあること。

vSphere 環境が上記の条件を満たさない場合でも、ユーザー クラスタをアップグレードできます。ただし、1.3.x から 1.4.x にアップグレードする場合は、反アフィニティ グループを無効にする必要があります。詳細については、Anthos clusters on VMware のリリースノートの既知の問題をご覧ください。

アップグレード中のダウンタイムについて

リソース	説明
管理クラスタ	管理クラスタが停止しても、ユーザー クラスタのコントロール プレーンとワークロードは、ダウンタイムの原因となった障害の影響を受けない限り引き続き実行されます。
ユーザー クラスタのコントロール プレーン	通常、ユーザー クラスタ コントロール プレーンには目立ったダウンタイムはありません。ただし、Kubernetes API サーバーへの長時間実行の接続が切断され、再確立する必要がある場合があります。この場合、API 呼び出し元は、接続が確立するまで再試行する必要があります。最悪のケースでは、アップグレード中に最大 1 分間のダウンタイムが発生することがあります。 注: アップグレード中にユーザー クラスタノードがユーザー コントロール プレーンに到達できない場合、新しいワークロードはクラスタにスケジュールされません。既存のワークロードが影響を受けることはありません。
ユーザー クラスタノード	アップグレードでユーザー クラスタノードの変更が必要な場合、Anthos clusters on VMware はノードをローリング方式で再作成し、これらのノードで実行されている Pod を再スケジュールします。ワークロードへの影響を防ぐには、適切な PodDisruptionBudgets とアンチ アフィニティ ルールを構成します。

情報ファイルがない場合は再作成する

管理ワークステーションの出力情報ファイルがない場合にアップグレードを続行するには、このファイルを再作成する必要があります。このファイルは、最初にワークステーションを作成したときに作成され、その後アップグレードすると最新の情報で更新されていました。

出力情報ファイルは、次のような形式です。

Admin workstation version: GKEADM_VERSION
Created using gkeadm version: GKEADM_VERSION
VM name: ADMIN_WS_NAME
IP: ADMIN_WS_IP
SSH key used: FULL_PATH_TO_ADMIN_WS_SSH_KEY
To access your admin workstation:
ssh -i FULL-PATH-TO-ADMIN-WS-SSH-KEY ubuntu@ADMIN-WS-IP

出力情報ファイルの例を次に示します。

Admin workstation version: v1.10.3-gke.49
Created using gkeadm version: v1.10.3-gke.49
VM name: admin-ws-janedoe
IP: 172.16.91.21
SSH key used: /usr/local/google/home/janedoe/.ssh/gke-admin-workstation
Upgraded from (rollback version): v1.10.0-gke.194
To access your admin workstation:
ssh -i /usr/local/google/home/janedoe/.ssh/gke-admin-workstation ubuntu@172.16.91.21

パラメータを適切に置き換えて、エディタでファイルを作成します。gkeadm が実行されるディレクトリに、VM 名と同じファイル名でファイルを保存します。たとえば、VM 名が admin-ws-janedoe の場合は、ファイルを admin-ws-janedoe として保存します。