このページでは、Anthos clusters on VMware（GKE On-Prem）をアップグレードする方法について説明します。
アップグレード プロセスの概要
同じマイナー リリースか、その次のマイナー リリースに含まれるバージョンに直接アップグレードできます。たとえば、1.8.0 から 1.8.3、または 1.8.1 から 1.9.0 にアップグレードできます。
1 つ上のマイナー リリースの一部ではないバージョンにアップグレードする場合は、現在のバージョンと目的のバージョンの間の各マイナー バージョンを経由してアップグレードする必要があります。たとえば、バージョン 1.8.2 からバージョン 1.10.0 にアップグレードする場合、直接アップグレードすることはできません。まずバージョン 1.8.2 からバージョン 1.9.x にアップグレードした後、バージョン 1.10.0 にアップグレードする必要があります。
まず管理ワークステーションをアップグレードして、次にユーザー クラスタをアップグレードし、最後に管理クラスタをアップグレードします。管理クラスタを現在のバージョンのままにする場合、ユーザー クラスタをアップグレードした後すぐに管理クラスタをアップグレードする必要はありません。
gkeadmツールをダウンロードします。gkeadmのバージョンは、アップグレードのターゲット バージョンと同じにする必要があります。- 管理ワークステーションをアップグレードします。
- 管理ワークステーションから、ユーザー クラスタをアップグレードします。
- 管理ワークステーションから、管理クラスタをアップグレードします。
バージョン 1.9.x からバージョン 1.10.x への推奨アップグレード プロセス例
管理ワークステーション、管理クラスタ、ユーザー クラスタでバージョン 1.9.x を使用しており、管理クラスタとユーザー クラスタの両方をバージョン 1.10.x にアップグレードするとします。続行する前に、次に示すようなアップグレードの手順を踏んでカナリア クラスタでテストを行った後、先へ進むようにすると、中断のリスクを最小限に抑えることができます。
おすすめのアップグレード プロセスの概要を以下に示します。始める前に、バージョン 1.9.x を使用するカナリア ユーザー クラスタを作成します（まだ作成していない場合）。
- カナリア クラスタで、バージョン 1.10.x をテストします。
- 管理ワークステーションを、バージョン 1.10.x にアップグレードします。
- 後述するように、
gkectl prepareコマンドを実行してアップグレードを設定します。 - カナリア ユーザー クラスタを、バージョン 1.10.x にアップグレードします。
- バージョン 1.10.x で問題がなければ、すべての本番環境のユーザー クラスタをバージョン 1.10.x にアップグレードします。
- 管理クラスタを、バージョン 1.10.x にアップグレードします。
アップグレードの準備のため構成ファイルと情報ファイルを配置する
管理ワークステーションを作成する前に、gkeadm create config によって生成された管理ワークステーションの構成ファイルに入力しました。このファイルのデフォルト名は admin-ws-config.yaml です。
また、ワークステーションにも情報ファイルがあります。このファイルのデフォルト名は、現在の管理ワークステーションの名前と同じです。
管理ワークステーションの構成ファイルと情報ファイルを探します。これらのファイルはこのガイドの手順を実施するために必要です。これらのファイルが現在のディレクトリにあり、デフォルトの名前が使われている場合は、アップグレード コマンドを実行するときに名前を指定する必要はありません。これらのファイルが別のディレクトリにある場合や、ファイル名を変更した場合は、--config フラグと --info-file フラグを使用して指定します。
出力情報ファイルがない場合は、再作成できます。
存在しない場合は情報ファイルを再作成する
管理ワークステーションの出力情報ファイルがない場合にアップグレードを続行するには、このファイルを再作成する必要があります。このファイルは、最初にワークステーションを作成したときに作成され、その後アップグレードすると最新の情報で更新されていました。
出力情報ファイルの形式は次のとおりです。
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 として保存します。
管理ワークステーションのアップグレード
gkectl とクラスタがアップグレードに合ったバージョンになっており、適切なバンドルがダウンロードされていることを確認します。
次のコマンドを実行します。
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 を確保しておくことができます。
DHCP
管理クラスタをアップグレードすると、Anthos clusters on VMware は管理クラスタに一時的なノードを 1 つ作成します。ユーザー クラスタをアップグレードすると、Anthos clusters on VMware はユーザー クラスタに一時的なノードを作成します。一時ノードを作成する目的は可用性の維持です。クラスタをアップグレードする前に、DHCP サーバーが一時ノードに十分な IP アドレスを提供できることを確認してください。詳細については、管理クラスタとユーザー クラスタに必要な IP アドレスをご覧ください。
静的 IP
管理クラスタをアップグレードすると、Anthos clusters on VMware は管理クラスタに一時的なノードを 1 つ作成します。ユーザー クラスタをアップグレードすると、Anthos clusters on VMware はユーザー クラスタに一時的なノードを作成します。一時ノードを作成する目的は可用性の維持です。クラスタをアップグレードする前に、十分な数の IP アドレスが予約されていることを確認してください。クラスタごとに、クラスタノードの数よりも 1 つ以上多い IP アドレスを予約する必要があります。詳細については、静的 IP アドレスの構成をご覧ください。
管理クラスタのノード数を指定します。
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] get nodes
ここで、[ADMIN_CLUSTER_KUBECONFIG] は管理クラスタの kubeconfig ファイルのパスです。
次に、管理クラスタ用に予約されたアドレスを表示します。
kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -o yaml
出力の reservedAddresses フィールドに、管理クラスタノード用に予約されている IP アドレスの数が表示されます。たとえば、次の出力は、管理クラスタノード用に 5 つの IP アドレスが予約されていることを示しています。
...
reservedAddresses:
- gateway: 21.0.135.254
hostname: admin-node-1
ip: 21.0.133.41
netmask: 21
- gateway: 21.0.135.254
hostname: admin-node-2
ip: 21.0.133.50
netmask: 21
- gateway: 21.0.135.254
hostname: admin-node-3
ip: 21.0.133.56
netmask: 21
- gateway: 21.0.135.254
hostname: admin-node-4
ip: 21.0.133.47
netmask: 21
- gateway: 21.0.135.254
hostname: admin-node-5
ip: 21.0.133.44
netmask: 21
予約された IP アドレスの数は、管理クラスタ内のノードの数より少なくとも 1 つ以上多い数である必要があります。
バージョン 1.7 以降の場合は、管理クラスタに IP アドレスを追加します。
まず、次の例に示すように、IP ブロック ファイルを編集します。
blocks:
- netmask: "255.255.252.0"
ips:
- ip: 172.16.20.10
hostname: admin-host1
- ip: 172.16.20.11
hostname: admin-host2
# Newly-added IPs.
- ip: 172.16.20.12
hostname: admin-host3
次に、下のコマンドを実行して構成を更新します。
gkectl update admin --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [ADMIN_CONFIG_FILE]
[ADMIN_CLUSTER_KUBECONFIG] は、kubeconfig ファイルのパスです。
[ADMIN_CONFIG_FILE] は、管理構成ファイルのパスです。ファイルが現在のディレクトリにあり、名前が
admin-config.yamlの場合、このフラグを省略できます。
IP アドレスは削除できませんが、追加だけは可能です。
1.7 より前のバージョンの場合は、Cluster オブジェクトを直接編集してアドレスを追加できます。
クラスタ オブジェクトを開いて編集します。
kubectl edit cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]
reservedAddresses の下に gateway、hostname、ip、netmask を記載したブロックを追加します。
重要: 1.5.0 以降、ユーザー クラスタでは同じ手順が機能しないため、それぞれに gkectl update cluster を使用する必要があります。
ユーザー クラスタ内のノード数を確認するには:
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes
ここで、[USER_CLUSTER_KUBECONFIG] はユーザー クラスタの kubeconfig ファイルのパスです。
ユーザー クラスタ用に予約されたアドレスを表示するには:
kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \ -n [USER_CLUSTER_NAME] [USER_CLUSTER_NAME] -o yaml
ここで
[ADMIN_CLUSTER_KUBECONFIG] は、管理クラスタの kubeconfig ファイルのパスです。
[USER_CLUSTER_NAME] は、ユーザー クラスタの名前です。
予約された IP アドレスの数は、ユーザー クラスタ内のノードの数よりも 1 つ以上多い数にする必要があります。そうでない場合は、ユーザー クラスタの IP ブロック ファイルを開いて編集できます。
ユーザー クラスタ用に予約されているアドレスのいずれかが IP ブロック ファイルに含まれている場合は、
netmaskとgatewayに基づいて、それらを対応するブロックに追加します。対応するブロックに静的 IP アドレスを必要な数だけ追加し、
gkectl update clusterを実行します。
アップグレード用のバンドルをインストールする
バージョンをクラスタの作成やアップグレードに使用できるようにするには、対応するバンドルをインストールする必要があります。次の手順に沿って、アップグレード先のバージョン（TARGET_VERSION） のバンドルをインストールします。
現在の gkectl とクラスタのバージョンを確認するには、次のコマンドを実行します。詳細は、フラグ --details/-d を使用して確認してください。
gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details
出力の例を次に示します。
gkectl version: 1.7.2-gke.2 (git-5b8ef94a3)onprem user cluster controller version: 1.6.2-gke.0 current admin cluster version: 1.6.2-gke.0 current user cluster versions (VERSION: CLUSTER_NAMES): - 1.6.2-gke.0: user-cluster1 available admin cluster versions: - 1.6.2-gke.0 available user cluster versions: - 1.6.2-gke.0 - 1.7.2-gke.2 Info: The admin workstation and gkectl is NOT ready to upgrade to "1.8" yet, because there are "1.6" clusters. Info: The admin cluster can't be upgraded to "1.7", because there are still "1.6" user clusters.
取得した出力に基づいて、次の問題を確認し、必要に応じて修正します。
gkectlバージョンが 1.7 未満の場合は、新しいアップグレード フローを直接利用できません。元のアップグレード フローに従ってすべてのクラスタを 1.6 にアップグレードしてから、管理ワークステーションを 1.7 にアップグレードして新しいアップグレード フローの使用を開始します。現在の管理クラスタのバージョンが TARGET_VERSION よりマイナー バージョンで 1 バージョン超低い場合は、すべてのクラスタを TARGET_VERSION より 1 マイナー バージョン低いバージョンにアップグレードします。
gkectlバージョンが TARGET_VERSION より低い場合は、手順に沿って管理ワークステーションを TARGET_VERSION にアップグレードします。
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/
バンドルをインストールします。
gkectl prepare --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz --kubeconfig ADMIN_CLUSTER_KUBECONFIG
ここで
- [ADMIN_CLUSTER_KUBECONFIG] は、kubeconfig ファイルのパスです。ファイルが現在のディレクトリにあり、名前が
kubeconfigの場合、このフラグを省略できます。
使用可能なクラスタ バージョンを一覧表示し、使用可能なユーザー クラスタ バージョンにターゲット バージョンが含まれていることを確認します。
gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details
これで、ターゲット バージョンでユーザー クラスタを作成することや、ユーザー クラスタをターゲット バージョンにアップグレードすることが可能になります。
アップグレード後に管理ワークステーションをロールバックする
管理ワークステーションは、アップグレード前に使用したバージョンにロールバックできます。
アップグレード中、gkeadm はアップグレード前のバージョンを出力情報ファイルに記録します。ロールバック中、gkeadm はリストされたバージョンを使用して古いファイルをダウンロードします。
管理ワークステーションを以前のバージョンにロールバックするには:
gkeadm rollback admin-workstation --config=AW_CONFIG_FILE
管理ワークステーション構成ファイルがデフォルトの admin-ws-config.yaml の場合は、--config=AW_CONFIG_FILE を省略できます。それ以外の場合は、AW_CONFIG_FILE を管理ワークステーションの構成ファイルのパスに置き換えます。
rollback コマンドは、次の手順を実行します。
gkeadmのロールバック バージョンをダウンロードします。- 現在の管理ワークステーションのホーム ディレクトリをバックアップします。
gkeadmのロールバック バージョンを使用して、新しい管理ワークステーションを作成します。- 元の管理ワークステーションを削除します。
ユーザー クラスタのアップグレード
アップグレードを続行する前に、次の点に注意してください。
ユーザー クラスタが登録解除されている場合は、ユーザー クラスタをバージョン 1.10 にアップグレードする前に登録する必要があります。
gkectl upgradeコマンドは、プリフライト チェックを実行します。プリフライト チェックが不合格の場合、コマンドはブロックされます。不備を修正するか、このコマンドでフラグ--skip-preflight-check-blockingを使用してブロックを解除する必要があります。バージョン 1.10 以降の Anthos clusters on VMware には、手動ロードバランサの
konnectivityServerNodePortが含まれています。アップグレードを行う前に、このノードポートに適切な値を指定し、このノードポートを使用してロードバランサを構成して、この新しいノードポートを構成ファイルに追加します。手動ロード バランシングをご覧ください。
管理ワークステーションで次の手順を行います。
管理クラスタ構成ファイルの
bundlepathフィールドが、アップグレード先のバンドルのパスと一致していることを確認します。ユーザー クラスタ構成ファイルの
gkeOnPremVersionフィールドが、アップグレード先のバージョンと一致することを確認します。管理クラスタ構成ファイルまたはユーザー クラスタ構成ファイルのフィールドで他の変更を行った場合、それらの変更はアップグレード時に無視されます。そうした変更を有効にするには、まずクラスタをアップグレードした後、構成ファイルを変更して更新コマンドを実行することで、他の変更をクラスタに施す必要があります。
次のコマンドでアップグレードします。
gkectl upgrade cluster \ --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \ --config [USER_CLUSTER_CONFIG_FILE] \ [FLAGS]
ここで
[ADMIN_CLUSTER_KUBECONFIG] は、管理クラスタの kubeconfig ファイルです。
[USER_CLUSTER_CONFIG_FILE] は、新しい管理ワークステーション上の Anthos clusters on VMware ユーザー クラスタの構成ファイルです。
[FLAGS] は、オプションのフラグのセットです。たとえば、vSphere インフラストラクチャのチェックをスキップする
--skip-validation-infraフラグを指定できます。
アップグレードの再開
ユーザー クラスタのアップグレードが中断された場合は、--skip-validation-all フラグを指定して同じアップグレード コマンドを使用すると、ユーザー クラスタのアップグレードを再開できます。
gkectl upgrade cluster \ --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \ --config [USER_CLUSTER_CONFIG_FILE] \ --skip-validation-all
管理クラスタのアップグレード
新しい管理ワークステーションで、このセクションの手順を行います。gkectl とクラスタがアップグレードに合ったバージョンになっており、適切なバンドルがダウンロードされていることを確認します。
管理クラスタ構成ファイルの
bundlepathフィールドが、アップグレード先のバンドルのパスと一致していることを確認します。管理クラスタ構成ファイルのフィールドで他の変更を行っている場合、その変更はアップグレード時に無視されます。そうした変更を有効にするには、まずクラスタをアップグレードした後、構成ファイルを変更して更新コマンドを実行することで、他の変更をクラスタに施す必要があります。
gkectl のバージョンは、目的のアップグレード バージョン以降でなければなりません。たとえば、gkectl のバージョンが 1.10.0 の場合は、クラスタを 1.10.0 または 1.9.x にアップグレードできます。すべてのユーザー クラスタが、同じマイナー バージョンまでアップグレードされた場合にのみ、管理クラスタをそのマイナー バージョンにアップグレードできます。
次のコマンドを実行します。
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
管理クラスタのアップグレードを再開する
管理クラスタのアップグレードが中断または失敗した場合で、管理クラスタのチェックポイントに、中断前の状態を復元するために必要な状態が含まれている場合は、アップグレードを再開できます。
手順は次のとおりです。
- 最初のアップグレードの実施を始める前に、管理コントロール プレーンが正常かどうかを確認します。
- 最初のアップグレード試行の前に、管理コントロール プレーンが正常でない場合は、
gkectl repair admin-masterコマンドで管理コントロール プレーンを修復します。 - アップグレードが中断または失敗した後にアップグレード コマンドを再実行すると、以前のアップグレード試行と同じバンドルとターゲット バージョンが使用されます。
アップグレード コマンドを再実行すると、再開されたアップグレードによってチェックポイントからその種類のクラスタの状態が再作成され、アップグレード全体が再実行されます。管理コントロール プレーンが正常でない場合は、最初に復元してから再びアップグレードを続行します。
管理クラスタのチェックポイントが使用可能な場合、アップグレードは失敗した時点か、終了した時点から再開されます。チェックポイントが使用できない場合は、アップグレードが管理コントロール プレーンへの依存にフォールバックするため、アップグレードを進めるには管理コントロール プレーンが正常である必要があります。アップグレードが成功すると、チェックポイントは再生成されます。
管理クラスタのアップグレード中に gkectl が予期せず終了した場合、その種類のクラスタはクリーンアップされません。アップグレード コマンドを再実行してアップグレードを再開する前に、その種類のクラスタを削除します。
docker stop gkectl-control-plane && docker rm gkectl-control-plane
種類クラスタを削除したら、アップグレード コマンドを再度実行します。
アップグレード プロセスのトラブルシューティング
推奨するアップグレード プロセスに従って問題が発生した場合は、次の手順で解決することをおすすめします。これらの推奨事項は、バージョン 1.6.2 のセットアップをすでに開始しており、推奨のアップグレード プロセスを進めることを前提としています。
ユーザー クラスタのアップグレードに関する問題のトラブルシューティング
カナリア クラスタのテスト時やユーザー クラスタのアップグレード時に 1.7 の問題が見つかった場合は、今後のパッチリリース 1.7.x で問題が解決することを Google サポートに確認します。次のように進めることができます。
- 本番環境には 1.6.2 を引き続き使用します。
- 1.7.x のパッチがリリースされたら、カナリア クラスタでそれをテストします。
- 問題ないと判断できる場合は、本番環境のすべてのユーザー クラスタを 1.7.x にアップグレードします。
- 管理クラスタを 1.7.x にアップグレードします。
1.7 のテストにおける 1.6.x パッチリリースの管理
1.7 のテストや 1.7 への移行プロセスを進めているが、確信が持てず、管理クラスタには 1.6.2 を使用しているとします。重要な 1.6.x のパッチがリリースされていることに気づきました。1.7 は引き続きテストしながら、1.6.x のメリットは享受できます。次のアップグレード プロセスに沿って行ってください。
- 1.6.x-gke.0 バンドルをインストールします。
- 1.6.2 のすべての本番環境ユーザー クラスタを 1.6.x にアップグレードします。
- 管理クラスタを 1.6.x にアップグレードします。
管理クラスタのアップグレードに関する問題のトラブルシューティング
管理クラスタのアップグレード中に問題が発生した場合は、Google サポートに連絡して管理クラスタの問題を解決する必要があります。
新しいアップグレード フローを使用すれば、管理クラスタのアップグレードでブロックされることなく、ユーザー クラスタの新機能を利用できます。これにより、必要に応じて管理クラスタのアップグレード頻度を減らすことができます。たとえば、バージョン 1.7 でリリースされた Container-Optimized OS ノードプールを使用できます。アップグレード プロセスは次のようになります。
- 本番環境のユーザー クラスタを 1.7 にアップグレードします。
- 管理クラスタは 1.6 のままにして、セキュリティ パッチを引き続き受信します。
- テスト環境で管理クラスタの 1.6 から 1.7 へのアップグレードをテストし、問題があれば報告します。
- 1.7 のパッチリリースで問題が解決した場合は、必要に応じて本番環境の管理クラスタを 1.6 からこの 1.7 パッチリリースにアップグレードすることもできます。
既知の問題
以下は、クラスタのアップグレードに関連する既知の問題です。
データディスクの残り容量が僅かになると、管理ワークステーションのアップグレードが失敗することがある
gkectl upgrade admin-workstation コマンドを使用して管理ワークステーションをアップグレード場合、データディスクの残り容量が僅かになるとアップグレードが失敗することがあります。これは、新しい管理ワークステーションへのアップグレード中に、現在の管理ワークステーションのバックアップがローカルで試行されるためです。データディスクの空き容量を確保できない場合は、--backup-to-local=false フラグが追加された gkectl upgrade admin-workstation コマンドを使用して、現在の管理ワークステーションのバックアップがローカルで作成されないようにします。
バージョン 1.7.0: Anthos Config Management のアップデートの変更
1.7.0 以前のバージョンでは、Anthos clusters on VMware には Anthos Config Management のインストールとアップグレードに必要なイメージが含まれていました。1.7.0 以降、Anthos Config Management ソフトウェアは Anthos clusters on VMware バンドルに含まれなくなったため、別途追加する必要があります。以前にクラスタで Anthos Config Management を使用していた場合は、操作を行うまでソフトウェアがアップグレードされません。
Anthos Config Management のインストールの詳細については、Anthos Config Management のインストールをご覧ください。
バージョン 1.1.0-gke.6、1.2.0-gke.6: stackdriver.proxyconfigsecretname フィールドが削除される
stackdriver.proxyconfigsecretname フィールドはバージョン 1.1.0-gke.6 で削除されました。フィールドが構成ファイルに存在する場合、Anthos clusters on VMware のプリフライト チェックはエラーを返します。
この問題を回避するには、1.2.0-gke.6 にアップグレードする前に構成ファイルから proxyconfigsecretname フィールドを削除しておきます。
Stackdriver が古いバージョンを参照する
バージョン 1.2.0-gke.6 以前では、Stackdriver はクラスタ アップグレードの後に構成を更新できないことが報告されています。Stackdriver は以前のバージョンを参照しているため、Stackdriver はテレメトリー パイプラインの最新の機能を受け取ることができません。この問題により、Google サポートによるクラスタのトラブル シューティングが難しくなることがあります。
クラスタを 1.2.0-gke.6 にアップグレードした後、管理クラスタとユーザー クラスタに対して次のコマンドを実行します。
kubectl --kubeconfig=[KUBECONFIG] \
-n kube-system --type=json patch stackdrivers stackdriver \
-p '[{"op":"remove","path":"/spec/version"}]'
ここで、[KUBECONFIG] はクラスタの kubeconfig ファイルへのパスです。
PodDisruptionBudgets を使用するワークロードが中断する
現時点では、クラスタをアップグレードすると、PodDisruptionBudgets（PDB）を使用するワークロードで中断やダウンタイムが発生することがあります。
バージョン 1.2.0-gke.6: アップグレード後に Prometheus と Grafana が無効になる
ユーザー クラスタでは、アップグレード中に Prometheus と Grafana は自動的に無効になります。ただし、構成データと指標データは失われません。管理クラスタでは、Prometheus と Grafana が引き続き有効です。
手順については、Anthos clusters on VMware のリリースノートをご覧ください。
バージョン 1.1.2-gke.0: 削除済みユーザー クラスタノードが vSAN データストアから削除されない
手順については、Anthos clusters on VMware のリリースノートをご覧ください。
バージョン 1.1.1-gke.2: vSAN データストア フォルダ内のデータディスクが削除できる
vSAN データストアを使用している場合は、VMDK を保存するフォルダを作成する必要があります。既知の問題により、フォルダのファイルパスではなく、Universally Unique Identifier（UUID）のパスを vcenter.datadisk に指定する必要があります。この不一致によりアップグレードが失敗する可能性があります。
手順については、Anthos clusters on VMware のリリースノートをご覧ください。
バージョン 1.0.2-gke.3 からバージョン 1.1.0-gke.6 にアップグレードする: OIDC に関する問題
OpenID Connect（OIDC）が構成されているバージョン 1.0.11、1.0.1-gke.5、1.0.2-gke.3 クラスタは、バージョン 1.1.0-gke.6 にアップグレードできません。この問題は、バージョン 1.1.1-gke.2 で修正されています。
インストール時にバージョン 1.0.11、1.0.1-gke.5、1.0.2-gke.3 のクラスタを OIDC で構成した場合、クラスタをアップグレードできません。代わりに、新しいクラスタを作成する必要があります。
バージョン 1.0.11 からバージョン 1.0.2-gke.3 にアップグレードする
バージョン 1.0.2-gke.3 では、次の OIDC フィールド（usercluster.oidc）が導入されています。これらのフィールドによって、Google Cloud コンソールからクラスタにログインできるようになります。
usercluster.oidc.kubectlredirecturlusercluster.oidc.clientsecretusercluster.oidc.usehttpproxy
OIDC を使用する場合、Google Cloud コンソールからクラスタにログインしない場合でも、clientsecret フィールドは必須です。OIDC を使用するには、clientsecret にプレースホルダの値を指定する必要があります。
oidc: clientsecret: "secret"
ノードがアップグレード プロセスを完了できない
追加の中断を許可できない 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 とアンチ アフィニティ ルールを構成します。 |
既知の問題
既知の問題をご覧ください。
トラブルシューティング
クラスタの作成とアップグレードに対するトラブルシューティングをご覧ください。