このページでは、Anthos clusters on VMware（GKE On-Prem）をアップグレードする方法について説明します。
ターゲット バージョン
Anthos clusters on VMware のバージョン 1.3.2 以降、同じマイナー リリースまたは次のマイナー リリースに含まれる任意のバージョンに直接アップグレードできます。たとえば、1.3.2 から 1.3.5、または 1.5.2 から 1.6.1 にアップグレードできます。
現在のバージョンが 1.3.2 より古い場合は、まず順次アップグレードを行い、バージョン 1.3.2 にする必要があります。たとえば、1.3.0 から 1.3.2 にアップグレードするには、1.3.0 から 1.3.1 にアップグレードしてから、1.3.1 から 1.3.2 にアップグレードする必要があります。
バージョン 1.3.2 以降から次のマイナー リリースに含まれないバージョンにアップグレードする場合は、現在のバージョンとその目的のバージョンの間にあるマイナー バージョンの 1 つからアップグレードする必要があります。たとえば、バージョン 1.3.2 からバージョン 1.6.1 にアップグレードする場合、直接アップグレードすることはできません。まず、バージョン 1.3.2 からバージョン 1.4.x にアップグレードする必要があります。x は、このマイナー リリースのすべてのパッチリリースを表します。その後、バージョン 1.5.x にアップグレードすると、最終的にバージョン 1.6.1 にアップグレードできます。
アップグレード プロセスの概要
gkeadmツールをダウンロードします。gkeadmのバージョンは、アップグレードのターゲット バージョンと同じにする必要があります。gkeadmを使用して管理ワークステーションをアップグレードします。管理ワークステーションから、管理クラスタをアップグレードします。
管理ワークステーションから、ユーザー クラスタをアップグレードします。
アップグレード ポリシー
管理クラスタをアップグレードした後:
新しく作成するユーザー クラスタには、管理クラスタと同じバージョンが必要です。
既存のユーザー クラスタをアップグレードする場合は、管理クラスタと同じバージョンにアップグレードする必要があります。
管理クラスタを再度アップグレードする前に、すべてのユーザー クラスタを現在の管理クラスタと同じバージョンにアップグレードする必要があります。
構成ファイルと情報ファイルの場所を探す
現在の管理ワークステーションを作成したときに、gkeadm create config によって生成された管理ワークステーション構成ファイルに入力しました。このファイルのデフォルト名は admin-ws-config.yaml です。
現在の管理ワークステーションを作成したときに、gkeadm によって情報ファイルが作成されています。このファイルのデフォルト名は、現在の管理ワークステーションの名前と同じです。
管理ワークステーションの構成ファイルと情報ファイルを探します。これらのファイルはこのガイドの手順を実施するために必要です。これらのファイルが現在のディレクトリにあり、デフォルトの名前が付いている場合は、gkeadm upgrade admin-workstation を実行するときにファイルを指定する必要はありません。これらのファイルが別のディレクトリにある場合や、ファイル名を変更した場合は、--config フラグと --info-file フラグを使用して指定します。
管理ワークステーションのアップグレード
管理ワークステーションをアップグレードするには、まず gkeadm ツールの新バージョンをダウンロードし、それを使用して管理ワークステーションの構成をアップグレードします。gkeadm のバージョンは、アップグレードのターゲット バージョンと一致する必要があります。
gkeadm のダウンロード
適切なバージョンの gkeadm をダウンロードするには、ダウンロード ページの手順を行ってください。
管理ワークステーションのアップグレード
gkeadm upgrade admin-workstation --config [AW_CONFIG_FILE] --info-file [INFO_FILE]
ここで
[AW_CONFIG_FILE] は、管理ワークステーションの構成ファイルのパスです。ファイルが現在のディレクトリにあり、名前が
admin-ws-config.yamlの場合、このフラグを省略できます。[INFO_FILE] は情報ファイルのパスです。ファイルが現在のディレクトリにある場合は、このフラグを省略できます。このファイルのデフォルト名は、管理ワークステーションの名前と同じです。
上記のコマンドによって、以下のタスクが実行されます。
現在の管理ワークステーションのホーム ディレクトリにあるすべてのファイルをバックアップします。たとえば、次のようなものです。
Anthos clusters on VMware の構成ファイル。このファイルのデフォルト名は
config.yamlです。管理クラスタとユーザー クラスタの kubeconfig ファイル
vCenter サーバーのルート証明書（このファイルにはオーナーの読み取り権限とオーナーの書き込み権限が必要）。
コンポーネント アクセス サービス アカウントの JSON キーファイル（このファイルにはオーナーの読み取り権限とオーナーの書き込み権限が必要）。
connect-register、connect-agent、logging-monitoring サービス アカウントの JSON キーファイル。
新しい管理ワークステーションを作成し、バックアップされたすべてのファイルを新しい管理ワークステーションにコピーします。
古い管理ワークステーションを削除します。
ノード OS イメージと Docker イメージを更新する
新しい管理ワークステーションで、次のコマンドを実行します。
gkectl prepare --config [ADMIN_CONFIG] [FLAGS]
ここで
[ADMIN_CONFIG] は、管理クラスタの構成ファイルのパスです。
[FLAGS] は、オプションのフラグのセットです。たとえば、vSphere インフラストラクチャのチェックをスキップする
--skip-validation-infraフラグを指定できます。
上記のコマンドによって、以下のタスクが実行されます。
必要に応じて、vSphere 環境に新しいノードの OS イメージをコピーし、その OS イメージをテンプレートとしてマークします。
非公開 Docker レジストリを構成した場合は、更新された Docker イメージを非公開 Docker レジストリに push します。
十分な 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 つ以上多い数である必要があります。そうでない場合は、クラスタ オブジェクトを編集して追加のアドレスを予約できます。
クラスタ オブジェクトを開いて編集します。
kubectl edit cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]
reservedAddresses の下に gateway、hostname、ip、netmask を記載したブロックを追加します。
ユーザー クラスタ内のノード数を確認するには:
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 アドレスを追加してファイルを閉じます。
ユーザー クラスタを更新します。
gkectl update cluster --kubeconfig [ADMIN_CLUSTER_KUBECONIFG] \ --config [USER_CLUSTER_CONFIG]
（省略可）新しい vSphere 機能を無効にする
新しい Anthos clusters on VMware のバージョンには、特定の VMware vSphere 機能の新機能やサポートが含まれていることがあります。Anthos clusters on VMware にアップグレードすると、これらの機能が自動的に有効になることがあります。新機能については、Anthos clusters on VMware のリリースノートをご覧ください。Anthos clusters on VMware の構成ファイルに新しい機能が表示されることがあります。
Anthos clusters on VMware の新しいバージョンで自動的に有効になり、構成ファイルで実行される新機能を無効にする必要がある場合は、以下の手順を行ってからクラスタをアップグレードします。
アップグレードした管理ワークステーションから、現在の構成ファイルとは異なる名前で新しい構成ファイルを作成します。
gkectl create-config --config [CONFIG_NAME]
新しい構成ファイルを開き、機能のフィールドをメモしておきます。ファイルを閉じます。
現在の構成ファイルを開き、新しい機能のフィールドを追加します。フィールドの値を
falseまたは同等の値に設定します。構成ファイルを保存します。
クラスタをアップグレードする前に、リリースノートを確認してください。アップグレード後に既存のクラスタの構成を宣言型の方法で変更することはできません。
管理クラスタのアップグレード
新しい管理ワークステーションで、このセクションの手順を行います。
アップグレードのターゲット バージョンは gkeadm バージョンと同じでなければなりません。
次のコマンドを実行します。
gkectl upgrade admin \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [ADMIN_CLUSTER_CONFIG_FILE] \
[FLAGS]
ここで
[ADMIN_CLUSTER_KUBECONFIG] は、管理クラスタの kubeconfig ファイルのパスです。
[ADMIN_CLUSTER_CONFIG_FILE] は、管理クラスタの構成ファイルのパスです。
[FLAGS] は、オプションのフラグのセットです。たとえば、vSphere インフラストラクチャのチェックをスキップする
--skip-validation-infraフラグを指定できます。
ユーザー クラスタのアップグレード
新しい管理ワークステーションで、このセクションの手順を行います。
アップグレードのターゲット バージョンは gkeadm バージョンと同じでなければなりません。
gkectl
gkectl upgrade cluster \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [USER_CLUSTER_CONFIG_FILE] \
[FLAGS]
ここで
[ADMIN_CLUSTER_KUBECONFIG] は管理クラスタの kubeconfig ファイルのパスです。
[USER_CLUSTER_CONFIG_FILE] は、ユーザー クラスタの構成ファイルのパスです。
[FLAGS] は、オプションのフラグのセットです。たとえば、vSphere インフラストラクチャのチェックをスキップする
--skip-validation-infraフラグを指定できます。
Console
ユーザー クラスタは、インストール時または作成後に Google Cloud コンソールに登録できます。Google Cloud コンソールで、登録済みの Anthos クラスタと GKE クラスタを表示してログインできます。
ユーザー クラスタのアップグレードが有効になると、Google Cloud コンソールに通知が表示されます。この通知をクリックすると、使用可能なバージョンのリストとクラスタをアップグレードするために実行できる gkectl コマンドが表示されます。
Google Cloud コンソールで Google Kubernetes Engine ページに移動します。
ユーザー クラスタの [通知] 列に、[アップグレード可能] があればそれをクリックします。
gkectl upgrade clusterコマンドをコピーします。管理ワークステーションで、
gkectl upgrade clusterコマンドを実行します。ここで、[ADMIN_CLUSTER_KUBECONFIG] は管理クラスタの kubeconfig ファイルのパス、[CLUSTER_NAME] はアップグレードするユーザー クラスタの名前、[USER_CLUSTER_CONFIG_FILE] はユーザー クラスタ構成ファイルのパスです。
アップグレードの再開
ユーザー クラスタのアップグレードが中断された場合は、--skip-validation-all フラグを指定して同じアップグレード コマンドを使用すると、ユーザー クラスタのアップグレードを再開できます。
gkectl upgrade cluster \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [USER_CLUSTER_CONFIG_FILE] \
--cluster-name [CLUSTER_NAME] \
--skip-validation-all
管理クラスタのアップグレードを再開する
管理クラスタのアップグレードは中断しないでください。現時点では、管理クラスタのアップグレードは常に再開できるとは限りません。なんらかの理由で管理クラスタのアップグレードが中断された場合は、サポートにお問い合わせください。
アップグレード後に新しいユーザー クラスタを作成する
管理ワークステーションと管理クラスタをアップグレードした後は、作成する新しいユーザー クラスタのバージョンがアップグレードのターゲット バージョンと同じである必要があります。
VMware DRS ルール
Anthos clusters on VMware はユーザー クラスタのノードに対して VMware Distributed Resource Scheduler（DRS）の反アフィニティ ルールを自動的に作成し、データセンター内の少なくとも 3 つの物理ホストにそれを分散させます。この機能は新しいクラスタと既存のクラスタで自動的に有効になります。
アップグレードを行う前に、vSphere 環境が次の条件を満たしていることを確認してください。
- VMware DRS が有効になっていること。VMware DRS には、vSphere Enterprise Plus ライセンス エディションが必要です。DRS を有効にする方法については、クラスタ内の VMware DRS の有効化をご覧ください。
vcenterフィールドで指定された vSphere ユーザー アカウントにHost.Inventory.EditCluster権限があること。- 利用可能な物理ホストが少なくとも 3 つあること。
vSphere 環境が上記の条件を満たさない場合でも、ユーザー クラスタをアップグレードできます。ただし、1.3.x から 1.4.x にアップグレードする場合は、反アフィニティ グループを無効にする必要があります。詳細は、バージョン 1.4.0 のリリースノートをご覧ください。
ダウンタイム
アップグレード中のダウンタイムについて
| リソース | 説明 |
|---|---|
| 管理クラスタ | 管理クラスタが停止しても、ユーザー クラスタのコントロール プレーンとワークロードは、ダウンタイムの原因となった障害の影響を受けない限り引き続き実行されます。 |
| ユーザー クラスタのコントロール プレーン | 通常、ユーザー クラスタ コントロール プレーンには目立ったダウンタイムはありません。ただし、Kubernetes API サーバーへの長時間実行の接続が切断され、再確立する必要がある場合があります。この場合、API 呼び出し元は、接続が確立するまで再試行する必要があります。最悪のケースでは、アップグレード中に最大 1 分間のダウンタイムが発生することがあります。 |
| ユーザー クラスタノード | アップグレードでユーザー クラスタノードの変更が必要な場合、Anthos clusters on VMware はノードをローリング方式で再作成し、これらのノードで実行されている Pod を再スケジュールします。ワークロードへの影響を防ぐには、適切な PodDisruptionBudgets とアンチ アフィニティ ルールを構成します。 |
既知の問題
既知の問題をご覧ください。
トラブルシューティング
クラスタの作成とアップグレードに対するトラブルシューティングをご覧ください。