このページでは、VMware 上の Google Distributed Cloud(ソフトウェアのみ)で作成されたユーザー クラスタで、コントロール プレーンとノードプールを個別にアップグレードする方法について説明します。このページは、基盤となる技術インフラストラクチャのライフサイクルを管理する IT 管理者と運用担当者を対象としています。 Google Cloud のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE ユーザーのロールとタスクをご覧ください。このドキュメントを読む前に、次のページに記載されている Google Distributed Cloud のアップグレードの計画と実行についてよく理解しておいてください。
制限事項
コントロール プレーンとは別にノードプールをアップグレードする場合、次の制限があります。
- この機能は、Ubuntu ノードプールと COS ノードプールではサポートされていますが、Windows ノードプールではサポートされていません。 
- この機能は、高度でないクラスタを高度なクラスタにアップグレードする場合には使用できません。高度でないクラスタは、1.33 で高度なクラスタに自動的にアップグレードされます。 
- バージョン 1.31: この機能は高度なクラスタでは使用できません。 
- バージョン 1.32 以降: この機能は高度なクラスタで使用できます。 
コントロール プレーンとノードプールを個別にアップグレードする理由
- クラスタのバージョンが 1.16 以降の場合は、ノードプールをアップグレードするときにマイナー バージョンをスキップできます。バージョン スキップ アップグレードを行うと、ノードプールの 2 つのバージョンを順番にアップグレードする場合に比べて、所要時間が半分に短縮されます。また、バージョン スキップ アップグレードを使用すると、サポート対象のバージョンを維持するために必要なアップグレードの間隔を長くできます。アップグレードの回数を減らすと、ワークロードの中断と検証時間が短縮されます。詳細については、ノードプールのアップグレードでバージョンをスキップするをご覧ください。 
- 状況によっては、ユーザー クラスタ内のすべてのノードプールではなく、一部のノードプールをアップグレードすることをおすすめします。例: - 最初に、コントロール プレーンと、トラフィックが少ないノードプールまたは重要度の低いワークロードを実行するノードプールをアップグレードします。ワークロードが新しいバージョンで正しく実行されることを確認したら、最終的にすべてのノードプールがアップグレードされるまで、追加のノードプールをアップグレードします。 
- クラスタのアップグレードに 1 つの大きなメンテナンスの時間枠を設定するのではなく、複数のメンテナンスの時間枠でクラスタをアップグレードできます。メンテナンスの時間枠を見積もる方法については、所要時間を見積もり、メンテナンスの時間枠を計画するをご覧ください。 
 
始める前に
- バージョン 1.29 以降では、サーバーサイドのプリフライト チェックがデフォルトで有効になっています。ファイアウォール ルールを確認し、必要に応じて変更してください。 
- バージョン 1.28 以降にアップグレードするには、 - kubernetesmetadata.googleapis.comを有効にして、logging-monitoring サービス アカウントに- kubernetesmetadata.publisherIAM ロールを付与する必要があります。詳細については、Google API と IAM の要件をご覧ください。
- クラスタの現在のバージョンがバージョン 1.14 以降であることを確認します。 
コントロール プレーンと選択したノードプールをアップグレードする
ワーカー ノードプールとは別にユーザー クラスタのコントロール プレーンをアップグレードするには、gkectl、Google Cloud CLI、または Terraform を使用します。Terraform を使用してアップグレードできるのは、Terraform を使用して作成したユーザー クラスタだけです。
gkectl
- 次のプレースホルダ変数に、ソース バージョンとターゲット バージョンを定義します。バージョンはすべて、 - 1.16.11-gke.25など、- x.y.z-gke.N形式の完全なバージョン番号にする必要があります。- バージョン - 説明 - SOURCE_VERSION- 現在のクラスタ バージョン。 - TARGET_VERSION- ターゲット バージョンを選択します。ターゲット マイナー バージョンから推奨されるパッチを選択します。 
- 管理ワークステーションをターゲット バージョンにアップグレードします。アップグレードが正常に完了したことを示すメッセージが表示されるまで待ちます。 
- 対応する OS イメージを vSphere にインポートします。 - gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG - ADMIN_CLUSTER_KUBECONFIGは、管理クラスタの- kubeconfigファイルのパスに置き換えます。
- ユーザー クラスタの構成ファイルを次のように変更します。 - gkeOnPremVersionフィールドをターゲット バージョン- TARGET_VERSIONに設定します。
- アップグレードするノードプールごとに、 - nodePools.nodePool[i].gkeOnPremVersionフィールドを空の文字列に設定します。- バージョン 1.28 以降では、nodePools.nodePool[i].updateStrategy.rollingUpdate.maxSurgeフィールドを 1 より大きい整数値に設定することで、ノードプールのアップグレードを高速化できます。maxSurgeを使用してノードをアップグレードすると、単一ノードのアップグレードにかかる時間と同じ時間で複数のノードをアップグレードできます。
 
- バージョン 1.28 以降では、
- アップグレードしないノードプールごとに、 - nodePools.nodePool[i].gkeOnPremVersionをソース バージョン(- SOURCE_VERSION)に設定します。
 - 次の例は、ユーザー クラスタ構成ファイルの一部を示しています。コントロール プレーンと - pool-1が- TARGET_VERSIONにアップグレードされるように指定していますが、- pool-2は- SOURCE_VERSIONのままです。- gkeOnPremVersion: TARGET_VERSION ... nodePools: - name: pool-1 gkeOnPremVersion: "" ... - name: pool-2 gkeOnPremVersion: SOURCE_VERSION ...
- コントロール プレーンと選択したノードプールをアップグレードします。 - gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILE - USER_CLUSTER_CONFIGは、ユーザー クラスタ構成ファイルのパスに置き換えます。
追加のノードプールをアップグレードする
前の例で、pool-1 ですべてが正常に動作しており、pool-2 をアップグレードする場合について考えてみましょう。
- ユーザー クラスタの構成ファイルで、 - pool-2の下の- gkeOnPremVersionを空の文字列に設定します。- gkeOnPremVersion: TARGET_VERSION ... nodePools: - name: pool-1 gkeOnPremVersion: "" ... - name: pool-2 gkeOnPremVersion: "" ...
- gkectl update clusterを実行して変更を適用します。- gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG 
gcloud CLI
ユーザー クラスタをアップグレードするには、管理クラスタにいくつかの変更を加える必要があります。gcloud container vmware clusters upgrade コマンドは、自動的に次の処理を行います。
- 管理クラスタを GKE On-Prem API に登録します(まだ登録されていない場合)。 
- コンポーネントのバンドルをダウンロードして管理クラスタにデプロイします。コンポーネントのバージョンが、アップグレードに指定したバージョンと一致します。これらのコンポーネントを使用すると、管理クラスタがそのバージョンのユーザー クラスタを管理できるようになります。 
コントロール プレーンをアップグレードする
ユーザー クラスタのコントロール プレーンを次の手順でアップグレードします。
- Google Cloud CLI のコンポーネントを更新します。 - gcloud components update
- クラスタのアップグレード ポリシーを変更します。 - 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 upgrade USER_CLUSTER_NAME \ --project=PROJECT_ID \ --location=REGION \ --version=TARGET_VERSION - TARGET_VERSIONは、アップグレードするバージョンに置き換えます。ターゲット マイナー バージョンから推奨されるパッチを選択します。- このコマンドからの出力は、次のようになります。 - 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=TARGET_VERSION 
Terraform
- Google Cloud CLI のコンポーネントを更新します。 - gcloud components update
- まだ行っていない場合は、GKE On-Prem API に管理クラスタを登録します。クラスタが GKE On-Prem API に登録された後は、この手順を繰り返す必要はありません。 
- 新しいバージョンのコンポーネントをダウンロードして、管理クラスタにデプロイします。 - gcloud vmware admin-clusters update ADMIN_CLUSTER_NAME \ --project=PROJECT_ID \ --location=REGION \ --required-platform-version=TARGET_VERSION - 次のように置き換えます。 - 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 にクラスタを登録したときに指定したリージョンです。
- TARGET_VERSION: アップグレードするバージョン。ターゲット マイナー バージョンから推奨されるパッチを選択します。
 - このコマンドは、 - --required-platform-versionで指定したバージョンのコンポーネントを管理クラスタにダウンロードし、そのコンポーネントをデプロイします。これらのコンポーネントを使用すると、管理クラスタがそのバージョンのユーザー クラスタを管理できるようになります。
- ユーザー クラスタの作成に使用した - main.tfファイルで、クラスタ リソースの- on_prem_versionを新しいバージョンに変更します。
- コントロール プレーンのみがアップグレードされるように、クラスタ リソースに次のコードを追加します。 - upgrade_policy { control_plane_only = true }
- Terraform プランを初期化して作成します。 - terraform init- Google Cloudプロバイダなどの必要なライブラリがインストールされます。 
- 構成を確認し、必要に応じて変更を加えます。 - terraform plan
- Terraform プランを適用して、ユーザー クラスタを作成します。 - terraform apply
ノードプールをアップグレードする
ユーザー クラスタのコントロール プレーンをアップグレードした後、次の手順でノードプールをアップグレードします。
- アップグレードする各ノードプールのリソースの - main.tfに、次の行を追加します。- on_prem_version = "TARGET_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
トラブルシューティング
ノードプールのアップグレード後に問題が発生した場合は、前のバージョンにロールバックできます。詳細については、アップグレード後にノードプールをロールバックするをご覧ください。