Anthos clusters on VMware は、VMware 用 Google Distributed Cloud（ソフトウェアのみ）になりました。詳細については、プロダクトの概要をご覧ください。

クラスタまたはノードプールをアップグレードする

このドキュメントでは、VMware 用 Google Distributed Cloud（ソフトウェアのみ）でクラスタとノードプールをアップグレードする方法について説明します。このドキュメントでは、管理ワークステーション、ユーザークラスタ、管理クラスタをアップグレードする手順について説明します。ユーザークラスタについては、コントロールプレーンとノードプールを同時にアップグレードする、または個別にアップグレードする手順を説明します。

このページは、基盤となる技術インフラストラクチャのライフサイクルを管理する IT 管理者と運用担当者を対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。

次に進む前に、以下のドキュメントを確認することをおすすめします。

アップグレードの概要
特にこのドキュメントでは、サポートされているバージョンスキューとバージョンルール（1.28 以降で変更）について説明します。
アップグレードのベストプラクティス
このドキュメントでは、クラスタをアップグレードするためのチェックリストとベストプラクティスについて説明します。

ファイアウォールルールを確認する

バージョン 1.29 以降では、サーバーサイドのプリフライトチェックはデフォルトで有効になっています。サーバーサイドのプリフライトチェックには、追加のファイアウォールルールが必要です。管理クラスタのファイアウォールルールで、[プリフライトチェック] を検索し、必要なファイアウォールルールがすべて構成されていることを確認します。

サーバーサイドのプリフライトチェックでは、gkectl を使用してユーザークラスタをアップグレードすると、プリフライトチェックは、管理ワークステーションでローカルではなく、管理クラスタで実行されます。Google Cloud コンソール、Google Cloud CLI、または Terraform を使用してクラスタをアップグレードすると、管理クラスタでサーバーサイドプリフライトチェックも実行されます。

管理クラスタをアップグレードすると、Google Distributed Cloud は Docker 内の Kubernetes（kind）クラスタをデプロイして、管理クラスタのアップグレードに必要な Kubernetes コントローラを一時的にホストします。この一時的なクラスタは、ブートストラップクラスタと呼ばれます。管理クラスタをアップグレードすると、ブートストラップクラスタでサーバーサイドのプリフライトチェックが実行されます。

Google API と IAM の要件

クラスタをバージョン 1.28 以降にアップグレードするには、kubernetesmetadata.googleapis.com を有効にして、logging-monitoring サービスアカウントに kubernetesmetadata.publisher IAM ロールを付与する必要があります。これらの変更は、Cloud Monitoring を使用するために必要です。

kubernetesmetadata.googleapis.com を有効にします。
```
gcloud services enable --project PROJECT_ID  \
    kubernetesmetadata.googleapis.com
```
PROJECT_ID は、クラスタがメンバーであるフリートホストプロジェクトの ID に置き換えます。これは、クラスタの作成時に指定したプロジェクトです。gkectl を使用してクラスタを作成した場合、これはクラスタ構成ファイルの gkeConnect.projectID フィールドのプロジェクト ID です。
Google API や他のアドレスからのトラフィックがプロキシサーバーを通過できるよう組織が許可リストを設定している場合は、kubernetesmetadata.googleapis.com を許可リストに追加します。
ロギングモニタリングサービスアカウントに kubernetesmetadata.publisher ロールを付与します。
```
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member "serviceAccount:SERVICE_ACCOUNT_EMAIL" \
  --role "roles/kubernetesmetadata.publisher"
```
SERVICE_ACCOUNT_EMAIL は、logging-monitoring サービスアカウントのメールアドレスに置き換えます。

ユーザークラスタをアップグレードするための IAM の要件

ユーザークラスタのアップグレードに gkectl を使用する場合は、このセクションをスキップしてください。

ユーザークラスタのアップグレードに Google Cloud コンソール、Google Cloud CLI、または Terraform を使用し、かつプロジェクトオーナーでない場合は、クラスタが作成された Google Cloud プロジェクトにおいて Identity and Access Management のロール roles/gkeonprem.admin が付与されている必要があります。このロールに含まれる権限の詳細については、IAM のドキュメントの GKE On-Prem ロールをご覧ください。

コンソールを使用してクラスタをアップグレードするには、少なくとも以下のものも必要となります。

roles/container.viewer。このロールを使用すると、ユーザーはコンソールで GKE クラスタのページやその他のコンテナリソースを表示できます。このロールに含まれる権限の詳細と、読み取り / 書き込み権限を持つロールの付与方法については、IAM のドキュメントで Kubernetes Engine ロールの説明をご覧ください。
roles/gkehub.viewer。このロールを使用すると、ユーザーはコンソールでクラスタを表示できます。このロールに含まれる権限の詳細と、読み取り / 書き込み権限を持つロールの付与方法については、IAM ドキュメントで GKE Hub ロールの説明をご覧ください。

アップグレードの前または後に構成を変更する

クラスタの構成を変更する必要がある場合は、アップグレードの前または後にクラスタの更新を行います。アップグレードに対して変更するクラスタ構成のは、バージョンのみです。クラスタのバージョンとタイプによっては、他の構成変更は通知なく無視されるか、アップグレードが失敗する原因になります。詳細については、サポートされていない変更を削除してアップグレードのブロックを解除するをご覧ください。

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

gkectl を使用してユーザークラスタをアップグレードする場合は、管理ワークステーションをアップグレードする必要があります。

コンソール、gcloud CLI、または Terraform を使用してユーザークラスタをアップグレードする場合は、さしあたり管理ワークステーションのアップグレードをスキップできます。しかし、管理クラスタのアップグレードは、gkectl のみがサポートしているため、管理クラスタをアップグレードする準備ができたら、管理ワークステーションをアップグレードする必要があります。

管理ワークステーションのアップグレード方法は、作成方法（gkeadm またはユーザー管理）によって異なります。

gkeadm

必要なファイルを探す

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

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

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

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

アップグレード

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

gkeadm をダウンロードします。
```
gkeadm upgrade gkeadm --target-version TARGET_VERSION
```
TARGET_VERSION は、アップグレードのターゲットバージョンに置き換えます。完全なバージョン番号を X.Y.Z-gke.N. の形式で指定する必要があります。 Google Distributed Cloud のバージョンのリストについては、バージョニングをご覧ください。
管理ワークステーションをアップグレードします。
```
gkeadm upgrade admin-workstation --config AW_CONFIG_FILE \
    --info-file INFO_FILE
```
次のように置き換えます。
- AW_CONFIG_FILE: 管理ワークステーションの構成ファイルのパス。ファイルが現在のディレクトリにあり、名前が admin-ws-config.yaml の場合、このフラグを省略できます。
- INFO_FILE: 情報ファイルのパスを指定します。ファイルが現在のディレクトリにある場合は、このフラグを省略できます。このファイルのデフォルト名は、管理ワークステーションの名前と同じです。

ユーザー管理

管理ワークステーションで、新しいバージョンの gkectl をインストールするディレクトリに移動します。

gkectl をダウンロードします。

gcloud storage cp gs://gke-on-prem-release/gkectl/VERSION/gkectl ./
chmod +x gkectl

VERSION は、アップグレードのターゲットバージョンに置き換えます。例: 1.30.200-gke.101。

Google Distributed Cloud バンドルをダウンロードします。バージョンが、gkectl のダウンロードに使用したバージョンと一致していることを確認します。

gcloud storage cp gs://gke-on-prem-release/gke-onprem-bundle/VERSION/gke-onprem-vsphere-VERSION.tgz ./

クラスタアップグレードに使用可能なバージョンを確認する

次のコマンドを実行して、アップグレードで利用可能なバージョンを確認します。

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG

出力に、現在のバージョンとアップグレードで利用可能なバージョンが表示されます。

アップグレードにコンソール、gcloud CLI、または Terraform を使用する場合、すべての Google Cloud リージョンの GKE On-Prem API でバージョンが使用可能になるまでリリースから約 7～10 日かかります。コンソールには、ユーザークラスタのアップグレードで利用可能なバージョンのみが一覧表示されます。gcloud CLI または Terraform を使用してユーザークラスタをアップグレードする手順には、gcloud container vmware clusters query-version-config を実行してアップグレードに使用可能なバージョンを取得する手順が含まれています。

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

ユーザークラスタは、gkectl、コンソール、gcloud CLI、または Terraform を使用してアップグレードできます。使用するツールの選定については、ユーザークラスタをアップグレードするツールを選択するをご覧ください。

gkectl

ユーザークラスタのアップグレードの準備を行う

管理ワークステーションで、次の操作を行います。

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

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

クラスタに Windows ノードプールがある場合は、gkectl prepare windows を実行してノードプールの osImage フィールドを更新します。詳しい手順については、Windows ノードプールを含むユーザークラスタをアップグレードするをご覧ください。
ユーザークラスタの構成ファイルで、gkeOnPremVersion をアップグレードのターゲットバージョンに設定します。
Ubuntu ノードプールと COS ノードプールのみ: アップグレードするノードプールを指定します。コントロールプレーンとは別にノードプールをアップグレードすることは、Ubuntu ノードプールと COS ノードプールではサポートされていますが、Windows ノードプールではサポートされていません。

ユーザークラスタの構成ファイルで、アップグレードするノードプールを次のように指定します。
- アップグレードするノードプールごとに、nodePools.nodePool[i].gkeOnPremVersion フィールドを削除するか、空の文字列に設定します。
- アップグレードしないノードプールごとに、nodePools.nodePool[i].gkeOnPremVersion を現在のバージョンに設定します。
たとえば、ユーザークラスタのバージョンが 1.15.5-gke.41 で、2 つのノードプール（pool-1 と pool-2）があるとします。また、コントロールプレーンと pool-1 は 1.16.3-gke.45 にアップグレードするが、pool-2 はバージョン 1.15.5-gke.41 のままにするとします。ユーザークラスタ構成ファイルの次の部分は、この例を指定する方法を示しています。
```
gkeOnPremVersion: 1.16.3-gke.45

nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  cpus: 4
  memoryMB: 8192
  replicas: 3
  osImageType: ubuntu_containerd
- name: pool-2
  gkeOnPremVersion: 1.15.5-gke.41
  cpus: 4
  memoryMB: 8192
  replicas: 5
  osImageType: ubuntu_containerd
```

プリフライトチェックを実行する

バージョン 1.29 以降にアップグレードする場合は、ユーザークラスタをアップグレードする前にプリフライトチェックを実行できます。

gkectl upgrade cluster \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG \
  --dry-run

--dry-run フラグを使用すると、gkectl upgrade cluster はプリフライトチェックを実行しますが、アップグレードプロセスは開始しません。以前のバージョンの Google Distributed Cloud では、プリフライトチェックが実行されますが、アップグレードとは別に実行することはできません。--dry-run フラグを追加すると、アップグレード前にプリフライトチェックでユーザークラスタで見つかった問題を見つけて修正できます。

`gkectl upgrade cluster` を実行します

gkectl upgrade cluster コマンドには次の 2 つのバリエーションがあります。

非同期: （推奨）
非同期のバリエーションでは、コマンドはアップグレードを開始して最後まで進みます。アップグレードの期間全体を通して、コマンドの出力を監視する必要はありません。そうする代わりに、gkectl list clusters と gkectl describe clusters を実行して、アップグレードの進行状況を定期的に確認できます。非同期のバリエーションを使用するには、コマンドに --async フラグを追加します。
同期:
同期のバリエーションでは、アップグレードが進むと、gkectl upgrade cluster コマンドにより管理ワークステーションにステータスメッセージが出力されます。

非同期アップグレード

1.16 以降のバージョンにアップグレードする場合は、この手順をスキップしてください。

ユーザークラスタに準備済みの認証情報と非公開レジストリを使用している場合は、ユーザークラスタをアップグレードする前に、非公開レジストリの認証情報が準備されていることを確認してください。非公開レジストリの認証情報を準備する方法については、ユーザークラスタの準備済みの認証情報を構成するをご覧ください。
管理ワークステーションで、非同期アップグレードを開始します。
```
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.30.0-gke.1
```
STATE の想定される値は、PROVISIONING、UPGRADING、DELETING、UPDATING、RUNNING、RECONCILING、ERROR、UNKNOWN です。

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

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

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

重要な各アップグレードフェーズの開始と終了のイベントが記録されます。たとえば、次のようなイベントが記録されます。

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 clusters に RUNNING の STATUS が表示されます。
```
NAMESPACE             NAME    READY   STATE     AGE     VERSION
my-uc-gkeonprem-mgmt  my-uc   True    RUNNING   9h      1.30.0-gke.1
```
また、アップグレードが完了すると、gkectl describe clusters によって Status の下に Last GKE On Prem Version フィールドが表示されます。例:
```
Status:
Cluster State:  RUNNING
Last GKE On Prem Version:  1.30.0-gke.1
```

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

タイムアウトは通常、PodDisruptionBudget（PDB）によってデッドロックが発生した結果生じます。その場合、古いノードから Pod を強制排除することはできず、古いノードをドレインすることもできません。Pod の強制排除に 10 分超を要する場合、OnPremUserCluster オブジェクトにイベントが書き込まれます。イベントをキャプチャするには、gkectl describe clusters を実行します。次に、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.16 以降のバージョンにアップグレードする場合は、この手順をスキップしてください。

ユーザークラスタに準備済みの認証情報と非公開レジストリを使用している場合は、ユーザークラスタをアップグレードする前に、非公開レジストリの認証情報が準備されていることを確認してください。非公開レジストリの認証情報を準備する方法については、ユーザークラスタの準備済みの認証情報を構成するをご覧ください。

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

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

バージョン 1.14.0 以降にアップグレードすると、ユーザークラスタ用に新しい kubeconfig ファイルが生成され、既存のファイルは上書きされます。ファイル内のクラスタの詳細を表示するには、次のコマンドを実行します。
```
kubectl config view --kubeconfig USER_CLUSTER_KUBECONFIG
```

追加のノードプールをアップグレードする

ユーザークラスタのコントロールプレーンのみをアップグレードした場合や、すべてのノードプールではなく、コントロールプレーンをアップグレードした場合は、次の手順でノードプールをアップグレードします。

ユーザークラスタの構成ファイルを編集します。アップグレードするノードプールごとに、次の例で示したように nodePools.nodePool[i].gkeOnPremVersion フィールドを削除するか、空の文字列に設定します。

gkeOnPremVersion: 1.16.3-gke.45

nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  cpus: 4
  memoryMB: 8192
  replicas: 3
  osImageType: ubuntu_containerd
- name: pool-2
  gkeOnPremVersion: ""
  cpus: 4
  memoryMB: 8192
  replicas: 5
  osImageType: ubuntu_containerd

gkectl update cluster を実行して変更を適用します。
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG
```
次のように置き換えます。
- ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス
- USER_CLUSTER_CONFIG: ユーザークラスタの構成ファイルのパス

ノードプールのアップグレード後に問題が発生した場合は、前のバージョンにロールバックできます。詳細については、アップグレード後のノードプールのロールバックをご覧ください。

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

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

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

コンソール

ユーザークラスタをアップグレードするには、管理クラスタにいくつかの変更を加える必要があります。コンソールでは、自動的に次の処理が行われます。

管理クラスタを GKE On-Prem API に登録します（まだ登録されていない場合）。
コンポーネントのバンドルをダウンロードして管理クラスタにデプロイします。コンポーネントのバージョンが、アップグレードに指定したバージョンと一致します。これらのコンポーネントを使用すると、管理クラスタがそのバージョンのユーザークラスタを管理できるようになります。

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

コンソールで、Google Kubernetes Engine クラスタの概要ページに移動します。

GKE クラスタに移動
Google Cloud プロジェクトを選択して、アップグレードするクラスタを選択します。
[詳細] パネルで、[詳細] をクリックします。
[クラスタの基本] セクションで、[ アップグレード] をクリックします。
[ターゲットバージョンの選択] リストで、アップグレード後のバージョンを選択します。キュレーションリストには、最新のパッチリリースのみが含まれます。
[アップグレード] をクリックします。

クラスタがアップグレードされる前にプリフライトチェックが実行され、クラスタのステータスとノードの健全性が検証されます。プリフライトチェックに合格すると、ユーザークラスタがアップグレードされます。アップグレードが完了するまでに約 30 分を要します。

アップグレードのステータスを表示するには、[クラスタの詳細] タブの [詳細を表示] をクリックします。

gcloud CLI

ユーザークラスタをアップグレードするには、管理クラスタにいくつかの変更を加える必要があります。gcloud container vmware clusters upgrade コマンドは、自動的に次の処理を行います。

管理クラスタを GKE On-Prem API に登録します（まだ登録されていない場合）。
コンポーネントのバンドルをダウンロードして管理クラスタにデプロイします。コンポーネントのバージョンが、アップグレードに指定したバージョンと一致します。これらのコンポーネントを使用すると、管理クラスタがそのバージョンのユーザークラスタを管理できるようになります。

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

Google Cloud CLI のコンポーネントを更新します。
```
gcloud components update
```
Ubuntu ノードプールと COS ノードプールのみ: ユーザークラスタのコントロールプレーンのみをアップグレードし、すべてのノードプールを現在のバージョンのままにしておく場合は、クラスタのアップグレードポリシーを変更します。
```
gcloud container vmware clusters update USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION \
  --upgrade-policy control-plane-only=True
```
次のように置き換えます。
- USER_CLUSTER_NAME: アップグレードするユーザークラスタの名前。
- PROJECT_ID: ユーザークラスタがメンバーであるフリートホストプロジェクトの ID。これは、クラスタの作成時に指定したプロジェクトです。gkectl を使用してクラスタを作成した場合、これはクラスタ構成ファイルの gkeConnect.projectID フィールドのプロジェクト ID です。
- REGION: GKE On-Prem API が稼働しメタデータを保存する Google Cloud リージョン。GKE On-Prem API クライアントを使用してクラスタを作成した場合、これはクラスタの作成時に選択したリージョンです。gkectl を使用してクラスタを作成した場合、これは GKE On-Prem API にクラスタを登録したときに指定したリージョンです。

アップグレード先として使用可能なバージョンのリストを取得します。

gcloud container vmware clusters query-version-config \
  --cluster=USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION

コマンドの出力は、次のようになります。

versions:
- version: 1.16.3-gke.45
- version: 1.16.2-gke.28
- version: 1.16.1-gke.45
- version: 1.16.0-gke.669
- version: 1.15.6-gke.25
- version: 1.15.5-gke.41

An Anthos version must be made available on the admin cluster ahead of the user
cluster creation or upgrade. Versions annotated with isInstalled=true are
installed on the admin cluster for the purpose of user cluster creation or
upgrade whereas other version are released and will be available for upgrade
once dependencies are resolved.

To install the version in the admin cluster, run:
$ gcloud container vmware admin-clusters update my-admin-cluster --required-platform-version=VERSION

バージョンのリストに続くメッセージは無視できます。アップグレード先のバージョンが管理者クラスタにインストールされているかどうかは関係ありません。upgrade コマンドは、upgrade コマンドで指定したバージョンに一致するコンポーネントのバンドルをダウンロードしてデプロイします。

クラスタをアップグレードします。update コマンドを実行してアップグレードポリシーを control-plane-only=True に変更した場合、クラスタのコントロールプレーンのみがアップグレードされます。それ以外の場合は、クラスタのコントロールプレーンとすべてのノードプールがアップグレードされます。
```
gcloud container vmware clusters upgrade USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION \
  --version=VERSION
```
VERSION は、アップグレード後の Google Distributed Cloud のバージョンに置き換えます。前のコマンドの出力にあるバージョンを指定します。最新のパッチバージョンにアップグレードすることをおすすめします。

このコマンドからの出力は、次のようになります。
```
Waiting for operation [projects/example-project-12345/locations/us-west1/operations/operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179] to complete.
```
この出力例で、operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179 という文字列は長時間実行オペレーションの OPERATION_ID です。オペレーションのステータスを確認するには、別のターミナルウィンドウで次のコマンドを実行します。
```
gcloud container vmware operations describe OPERATION_ID \
  --project=PROJECT_ID \
  --location=REGION
```

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

ユーザークラスタのコントロールプレーンのみをアップグレードする場合は、ユーザークラスタのコントロールプレーンをアップグレードした後、次の手順に沿ってノードプールをアップグレードします。

ユーザークラスタのノードプールのリストを取得します。

gcloud container vmware node-pools list
  --cluster=USER_CLUSTER_NAME  \
  --project=PROJECT_ID \
  --location=REGION

アップグレードするノードプールごとに、次のコマンドを実行します。

gcloud container vmware node-pools update NODE_POOL_NAME \
  --cluster=USER_CLUSTER_NAME  \
  --project=PROJECT_ID \
  --location=REGION \
  --version=VERSION

Terraform

Google Cloud CLI のコンポーネントを更新します。
```
gcloud components update
```
まだ行っていない場合は、GKE On-Prem API に管理クラスタを登録します。クラスタが GKE On-Prem API に登録された後は、この手順を繰り返す必要はありません。
アップグレード先として使用可能なバージョンのリストを取得します。
```
gcloud container vmware clusters query-version-config \
  --cluster=USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION
```
次のように置き換えます。
- USER_CLUSTER_NAME: ユーザークラスタの名前。
- PROJECT_ID: ユーザークラスタがメンバーであるフリートプロジェクトの ID。これは、クラスタの作成時に指定したプロジェクトです。gkectl を使用してクラスタを作成した場合、これはクラスタ構成ファイルの gkeConnect.projectID フィールドのプロジェクト ID です。
- REGION: GKE On-Prem API が稼働しメタデータを保存する Google Cloud リージョン。ユーザークラスタの作成に使用した main.tf ファイルでは、リージョンはクラスタリソースの location フィールドに設定されています。
コマンドの出力は、次のようになります。
```
versions:
- version: 1.16.3-gke.45
- version: 1.16.2-gke.28
- version: 1.16.1-gke.45
- version: 1.16.0-gke.669
- version: 1.15.6-gke.25
- version: 1.15.5-gke.41

An Anthos version must be made available on the admin cluster ahead of the user
cluster creation or upgrade. Versions annotated with isInstalled=true are
installed on the admin cluster for the purpose of user cluster creation or
upgrade whereas other version are released and will be available for upgrade
once dependencies are resolved.

To install the version in the admin cluster, run:
$ gcloud container vmware admin-clusters update my-admin-cluster --required-platform-version=VERSION
```
新しいバージョンのコンポーネントをダウンロードして、管理クラスタにデプロイします。
```
gcloud container vmware admin-clusters update ADMIN_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION \
  --required-platform-version=VERSION
```
このコマンドは、--required-platform-version で指定したバージョンのコンポーネントを管理クラスタにダウンロードし、そのコンポーネントをデプロイします。これらのコンポーネントを使用すると、管理クラスタがそのバージョンのユーザークラスタを管理できるようになります。
ユーザークラスタの作成に使用した main.tf ファイルで、クラスタリソースの on_prem_version を新しいバージョンに変更します。
Ubuntu ノードプールと COS ノードプールのみ: ユーザークラスタのコントロールプレーンのみをアップグレードし、すべてのノードプールを現在のバージョンのままにしておく場合は、クラスタリソースに次の行を追加します。
```
upgrade_policy {
  control_plane_only = true
}
```
Terraform プランを初期化して作成します。
```
terraform init
```
Terraform によって、Google Cloud プロバイダなどの必要なライブラリがインストールされます。
構成を確認し、必要に応じて変更を加えます。
```
terraform plan
```
Terraform プランを適用して、ユーザークラスタを作成します。
```
terraform apply
```

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

ユーザークラスタのコントロールプレーンのみをアップグレードする場合は、ユーザークラスタのコントロールプレーンをアップグレードした後、次の手順に沿って追加のノードプールをアップグレードします。

アップグレードする各ノードプールのリソースの main.tf に、次の行を追加します。

on_prem_version = "VERSION"

例:

resource "google_gkeonprem_vmware_node_pool" "nodepool-basic" {
name = "my-nodepool"
location = "us-west1"
vmware_cluster = google_gkeonprem_vmware_cluster.default-basic.name
config {
  replicas = 3
  image_type = "ubuntu_containerd"
  enable_load_balancer = true
}
on_prem_version = "1.16.0-gke.0"
}

Terraform プランを初期化して作成します。
```
terraform init
```
構成を確認し、必要に応じて変更を加えます。
```
terraform plan
```
Terraform プランを適用して、ユーザークラスタを作成します。
```
terraform apply
```

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

ユーザークラスタをアップグレードしたら、管理クラスタをアップグレードできます。

始める前に、次のことを行います。

バージョン 1.13 以降にアップグレードする場合は、まず管理クラスタ構成ファイルの gkeConnect セクションに入力して、管理クラスタを登録する必要があります。構成ファイルを変更してクラスタの gkectl 更新コマンドを実行します。
gkectl とクラスタがアップグレードに合ったバージョンになっており、適切なバンドルがダウンロードされていることを確認します。管理クラスタとユーザークラスタの間のバージョンスキューは、Google Distributed Cloud のバージョンによって異なります。管理クラスタをアップグレードできることを確認するには、管理クラスタとユーザークラスタのバージョンスキューをご覧ください。
管理クラスタ構成ファイルの bundlepath フィールドが、アップグレード先のバンドルのパスと一致していることを確認します。

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

`gkectl upgrade admin` を実行します

新しい管理ワークステーションで、このセクションの手順を行います。gkectl upgrade admin コマンドには次の 2 つのバリエーションがあります。

非同期:
非同期のバリエーションでは、コマンドはアップグレードを開始して最後まで進みます。アップグレードの期間全体を通して、コマンドの出力を監視する必要はありません。そうする代わりに、gkectl list admin と gkectl describe admin を実行して、アップグレードの進行状況を定期的に確認できます。非同期のバリエーションを使用するには、コマンドに --async フラグを追加します。

非同期アップグレードの要件:
- バージョン 1.29 以降の HA 管理クラスタでのみサポートされます。
- すべてのユーザークラスタで Controlplane V2 を有効にする必要があります。
同期:
同期のバリエーションでは、アップグレードが進むと、gkectl upgrade admin コマンドにより管理ワークステーションにステータスメッセージが出力されます。

非同期アップグレード

管理ワークステーションで、非同期アップグレードを開始します。
```
gkectl upgrade admin \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config ADMIN_CLUSTER_CONFIG_FILE \
  --async
```
次のように置き換えます。
- ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルへのパス。
- ADMIN_CLUSTER_CONFIG_FILE: 管理クラスタの構成ファイルへのパス。
上記のコマンドは完了し、アップグレードの進行中も管理ワークステーションを引き続き使用できます。

gkectl upgrade admin で、次のコマンドを実行します。
```
gkectl upgrade admin -h
```
アップグレードのステータスを確認するには:
```
gkectl list admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
出力には、クラスタ STATE の値が表示されます。クラスタがまだアップグレード中である場合、STATE の値は UPGRADING です。例:
```
NAME              STATE         AGE    VERSION
gke-admin-test    UPGRADING     9h     1.30.200-gke.101
```
STATE の想定される値は、RUNNING、UPGRADING、RECONCILING、ERROR、UNKNOWN です。

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

gkectl describe admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG

出力には、指定した管理クラスタの OnPremAdminCluster カスタムリソースが表示されます。これには、クラスタのステータス、状態、イベントが含まれます。

重要な各アップグレードフェーズの開始と終了のイベントが記録されます。

出力例:

Events:
Type    Reason                             Age   From                             Message
----       ------                                  ----     ----                                -------
Normal  ControlPlaneUpgradeStarted         40m   onprem-admin-cluster-controller  Creating or updating admin cluster API Controller
Normal  ControlPlaneMachineUpgradeStarted  40m   onprem-admin-cluster-controller  Creating or updating control plane machine
Normal  StatusChanged                      40m   onprem-admin-cluster-controller  OnPremAdminCluster status changed:
- New ClusterState condition: UPGRADING
- New Ready condition: False, CreateOrUpdateControlPlaneMachine, Creating or updating control plane machine
Normal   StatusChanged      2m                onprem-admin-cluster-controller  OnPremAdminCluster status changed:
- New ClusterState condition: RUNNING
- New Ready condition: True, ClusterRunning, Cluster is running

アップグレードが完了すると、gkectl list admin に RUNNING の STATUS が表示されます。
```
NAME              STATE         AGE    VERSION
gke-admin-test    RUNNING       9h     1.30.200-gke.101
```
また、アップグレードが完了すると、gkectl describe admin によって Status の下に Last GKE On Prem Version フィールドが表示されます。例:
```
Status:
  Cluster State:  RUNNING
  Last GKE On Prem Version:  1.30.0-gke.1
```

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

非同期アップグレードの場合、タイムアウト時間はクラスタ内のノードの数に基づきます。アップグレードがタイムアウト時間よりも長くかかる場合、アップグレードオペレーションがタイムアウトしたことを示すイベントが発生し、クラスタの状態が UPGRADING から ERROR に変更されます。ここで、ERROR 状態は、アップグレードに予想より長い時間がかかっているものの、終了されていないことを意味します。コントローラは整合を続行し、オペレーションを再試行し続けます。アップグレードがブロックされた、または失敗した場合は、 gkectl diagnose を実行して、一般的なクラスタの問題を確認できます。その結果に基づいて、手動で修正を行うか、Google Cloud サポートに連絡するかを決定できます。

同期アップグレード

次のコマンドを実行します。
```
gkectl upgrade admin \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config ADMIN_CLUSTER_CONFIG_FILE \
```
次のように置き換えます。
- ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。
- ADMIN_CLUSTER_CONFIG_FILE: 管理クラスタの構成ファイルへのパス。
gkectl upgrade コマンドは、プリフライトチェックを実行します。プリフライトチェックが不合格の場合、コマンドはブロックされます。不備を修正するか、このコマンドでフラグ --skip-preflight-check-blocking を使用してブロックを解除する必要があります。
バージョン 1.14.0 以降にアップグレードすると、管理クラスタ用に新しい kubeconfig ファイルが生成され、既存のファイルは上書きされます。ファイル内のクラスタの詳細を表示するには、次のコマンドを実行します。
```
kubectl config view --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```

フルバンドルを削除する

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

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

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

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

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

手順は次のとおりです。

最初のアップグレードの実施を始める前に、管理コントロールプレーンが正常かどうかを確認します。クラスタの問題を診断するをご覧ください。そのトピックで説明されているように、管理クラスタに対して gkectl diagnose cluster コマンドを実行します。
最初のアップグレード試行の前に、管理コントロールプレーンが正常でない場合は、gkectl repair admin-master コマンドで管理コントロールプレーンを修復します。
アップグレードが中断または失敗した後にアップグレードコマンドを再実行すると、以前のアップグレード試行と同じバンドルとターゲットバージョンが使用されます。

アップグレードコマンドを再実行すると、チェックポイントから管理クラスタの状態が再作成され、アップグレード全体が再実行されます。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 コマンドは、次の手順を実行します。

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

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

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

現在の gkectl とクラスタのバージョンを確認するには、次のコマンドを実行します。詳細は、フラグ --details/-d を使用して確認してください。
```
gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details
```
出力には、クラスタのバージョンに関する情報が表示されます。
取得した出力に基づいて、次の問題を確認し、必要に応じて修正します。
- 現在の管理クラスタのバージョンが TARGET_VERSION よりマイナーバージョンで 1 バージョン超低い場合は、すべてのクラスタを TARGET_VERSION より 1 マイナーバージョン低いバージョンにアップグレードします。
- gkectl バージョンが 1.11 未満で、1.12.x にアップグレードする場合は、アップグレードを複数回行う必要があります。1.11.x になるまではマイナーバージョンを 1 つずつアップグレードしてから、このトピックの手順に進んでください。
- gkectl バージョンが TARGET_VERSION より新しいバージョンの場合は、TARGET_VERSION に管理ワークステーションをアップグレードします。
gkectl とクラスタバージョンがアップグレードに適していると判断した場合は、バンドルをダウンロードします。

バンドルの tarball が管理ワークステーションに存在するかどうかを確認します。
```
stat /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz
```
バンドルが管理ワークステーションにない場合は、ダウンロードします。
```
gcloud storage cp gs://gke-on-prem-release/gke-onprem-bundle/TARGET_VERSION/gke-onprem-vsphere-TARGET_VERSION.tgz /var/lib/gke/bundles/
```
バンドルをインストールします。
```
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 にします。
使用可能なクラスタバージョンを一覧取得し、使用可能なユーザークラスタバージョンにターゲットバージョンが含まれていることを確認します。
```
gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details
```

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

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

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

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

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

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

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

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

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

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

本番環境のユーザークラスタを 1.12.x にアップグレードします。
管理クラスタは以前のバージョンのままにして、セキュリティパッチを引き続き受信します。
テスト環境で管理クラスタの 1.11.x から 1.12.x へのアップグレードをテストし、問題があれば報告します。
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 以降、Google Distributed Cloud はユーザークラスタのノードに対して 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 にアップグレードする場合は、反アフィニティグループを無効にする必要があります。詳細については、Google Distributed Cloud リリースノートのこの既知の問題をご覧ください。

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

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

次のステップ

gcloud CLI リファレンスドキュメント
Terraform リファレンスドキュメント
- google_gkeonprem_vmware_cluster
- google_gkeonprem_vmware_node_pool

クラスタまたはノードプールをアップグレードする

ファイアウォール ルールを確認する

Google API と IAM の要件

ユーザー クラスタをアップグレードするための IAM の要件

アップグレードの前または後に構成を変更する

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

gkeadm

必要なファイルを探す

アップグレード

ユーザー管理

クラスタ アップグレードに使用可能なバージョンを確認する

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

gkectl

ユーザー クラスタのアップグレードの準備を行う

プリフライト チェックを実行する

gkectl upgrade cluster を実行します

非同期アップグレード

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

同期アップグレード

追加のノードプールをアップグレードする

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

コンソール

gcloud CLI

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

Terraform

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

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

始める前に、次のことを行います。

gkectl upgrade admin を実行します

非同期アップグレード

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

同期アップグレード

フルバンドルを削除する

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

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

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

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

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

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

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

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

PodDisruptionBudgets を使用するワークロードが停止する

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

付録

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

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

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

次のステップ

ファイアウォールルールを確認する

ユーザークラスタをアップグレードするための IAM の要件

クラスタアップグレードに使用可能なバージョンを確認する

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

ユーザークラスタのアップグレードの準備を行う

プリフライトチェックを実行する

`gkectl upgrade cluster` を実行します

`gkectl upgrade admin` を実行します

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

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

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