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

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

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

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

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

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

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

  1. 管理ワークステーションをアップグレードします。

  2. 管理ワークステーションから、クラスタのアップグレードに使用するバンドルをインストールします。

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

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

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

管理ワークステーションを作成する前に、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 キーファイル。

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

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

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

クラスタをアップグレードする前に、十分な数の IP アドレスが割り振られているようにしてください。DHCP と静的 IP のそれぞれで説明するように、必要に応じて追加の IP を確保しておくことができます。複数のノードプールがある場合は、アップグレード プロセスを容易にするため、ノードプールごとに追加の IP アドレスも必要になります。

必要な IP アドレスの数を求めるには、ノード IP アドレスの管理をご覧ください。

アップグレードのバンドルを確認する

管理ワークステーションをアップグレードした場合は、そのワークステーションにクラスタをアップグレードするための対応するバンドル バージョンがあります。

管理ワークステーションのバージョンとは異なるバージョンを使用する場合は、対応するバンドルを手動でインストールする必要があります。アップグレード用のバンドルをインストールするをご覧ください。

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

コマンドライン

アップグレードを続行する前に、次の点に注意してください。

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

  • バージョン 1.10 以降の Anthos clusters on VMware には、手動ロードバランサの konnectivityServerNodePort が含まれています。アップグレードを行う前に、このノードポートに適切な値を指定し、このノードポートを使用してロードバランサを構成して、この新しいノードポートを構成ファイルに追加します。手動ロード バランシングをご覧ください。

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

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

  2. ユーザー クラスタ構成ファイルの gkeOnPremVersion フィールドが、アップグレード先のバージョンと一致することを確認します。

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

  3. 指定したディレクトリからクラスタにバンドルをインストールします。

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

    以下を置き換えます。

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

  4. 次のコマンドでアップグレードします。

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

    以下を置き換えます。

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

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

Console

  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

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

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

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

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

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

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

手順は次のとおりです。

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

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

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

アップグレード コマンドを再実行すると、再開されたアップグレードによってチェックポイントからその種類のクラスタの状態が再作成され、アップグレード全体が再実行されます。管理コントロール プレーンが正常でない場合は、最初に復元してから再びアップグレードを続行します。

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

管理クラスタのアップグレード中に 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.10 未満で、1.11.x にアップグレードする場合は、複数のアップグレードを行う必要があります。1.10.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 の場合、このフラグを省略できます。

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

    gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

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

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

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

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

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

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

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

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

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

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

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

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

アップグレードには、次の既知の問題が影響する可能性があります。

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

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

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 として保存します。