アップグレードの概要

VMware 用 Google Distributed Cloud ソフトウェアのみのクラスタ アップグレードを計画すると、必要なアップグレード順序を決定し、互換性のある管理ツールを選択して、マルチクラスタ環境でのワークロードの中断を最小限に抑えることができます。アップグレード前の準備チェックリストについては、アップグレードのベスト プラクティスをご覧ください。

バージョン、順序、ツールがアップグレードに与える影響

クラスタをアップグレードする順序、使用するツール、実行する必要があるチェックは、次の要素によって大きく異なります。

  • 開始するバージョン
  • アップグレードするバージョン
  • 高度なクラスタまたは高度なクラスタ以外のクラスタからアップグレードするかどうか
  • 高度なクラスタまたは高度なクラスタ以外のクラスタにアップグレードするかどうか
  • ユーザー クラスタで Controlplane V2 が有効になっているかどうか

開始するバージョン、クラスタをアップグレードする順序、更新に使用するツール、クラスタのバージョン、実行できることとできないことは、大きく異なります。

クラスタが高度なクラスタか高度なクラスタ以外かを確認する

クラスタが高度なクラスタか高度なクラスタ以外かを確認するには、使用しているバージョンを特定します。

  • クラスタでバージョン 1.30 以前を使用している場合、それらは高度なクラスタではありません。
  • クラスタでバージョン 1.33 を使用していて、高度なクラスタを明示的にオプトアウトしていない場合、それらは高度なクラスタです。
  • クラスタでバージョン 1.34 以降を使用している場合、それらは高度なクラスタです。

クラスタでバージョン 1.31 と 1.32 を使用している場合は、kubectl を使用してクラスタのカスタム リソースを確認し、クラスタが高度なクラスタかどうかを確認します。

  1. 管理クラスタの kubeconfig で、管理クラスタの enableAdvancedCluster 仕様フィールドを確認します。

    kubectl get onpremadminclusters -A \
    -o custom-columns=NAME:.metadata.name,VERSION:.spec.gkeOnPremVersion,ADVANCED:.spec.enableAdvancedCluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    ADMIN_CLUSTER_KUBECONFIG は、管理クラスタ kubeconfig ファイルのパスに置き換えます。

  2. 管理クラスタの kubeconfig で、ユーザー クラスタの enableAdvancedCluster 仕様フィールドを確認します。

    kubectl get onpremuserclusters -A \
    -o custom-columns=NAME:.metadata.name,VERSION:.spec.gkeOnPremVersion,ADVANCED:.spec.enableAdvancedCluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

高度なクラスタが有効になっている場合、出力は次のようになります。

NAME              VERSION           ADVANCED
gke-admin-abc12   1.32.0-gke.1085   true

ADVANCED が true の場合、高度なクラスタです。バージョン 1.32 以前では、ADVANCED が <none> と表示されることがあります。

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

以降のセクションでは、アップグレード元とアップグレード先のクラスタのタイプに応じて、クラスタをアップグレードする際のアップグレード プロセスの全体像について説明します。

アップグレードを開始する前に、バージョンがアップグレードに与える影響について詳細を確認してください。バージョン別の依存関係の詳細なリスト、バージョンのスキップとバージョン スキュー ルールについては、アップグレード バージョン ルールをご覧ください。

高度なクラスタと高度なクラスタ以外のクラスタ

クラスタには、高度なクラスタと高度でないクラスタの 2 種類があります。バージョン 1.33 以降で作成されたクラスタはすべて高度なクラスタです。高度なクラスタでは、柔軟性とスケーラビリティを向上させる改良されたアーキテクチャが使用されます。

クラスタを高度なクラスタにアップグレードすると、常に高度なクラスタを使用し、高度なクラスタのアップグレード プロセスを使用します。クラスタが高度なクラスタか高度なクラスタ以外かは、1.33 より前のバージョンからアップグレードする場合にのみ重要です。

高度なクラスタは、ベアメタル用の Google Distributed Cloud ソフトウェアのみを VMware 用の Google Distributed Cloud ソフトウェアのみの基盤となるフレームワークとして使用することで、統合された Google Distributed Cloud アーキテクチャを使用します。ノードラベル、API リソース、システムタグに「ベアメタル」という参照が表示されることがあります。

高度なクラスタ機能は、VMware 用 Google Distributed Cloud ソフトウェアのみと他の Google Distributed Cloud プロダクトをより適切に調整するクラスタ アーキテクチャを実装します。高度なクラスタが有効になっているクラスタは、他の Google Distributed Cloud クラスタとプラットフォームを共有します。この共有プラットフォームでは同じコントローラとエージェントが使用されるため、信頼性が向上し、Google がより優れたサポートを提供できるようになります。また、高度なクラスタが有効になっている場合、クラスタ操作のパフォーマンスも向上します。

新しいアーキテクチャでは、他のすべての Google Distributed Cloud サービスと一貫したエクスペリエンスと実装が実現されます。高度なクラスタと高度なクラスタ以外のクラスタで使用できる機能の詳細については、高度なクラスタ機能のサポートをご覧ください。

高度なクラスタから高度なクラスタへのアップグレード（現在のバージョン、1.31 以降）

バージョン 1.32 以降では、高度なクラスタ間でアップグレードする場合、パッチ バージョンのアップグレードと、連続するマイナー バージョンのアップグレードの両方を実行できます。バージョン 1.31 プレビューでは、バージョン 1.31 内でのパッチ バージョンのアップグレードのみを実行できます。

このアップグレードを実行するには、gkectl CLI、Google Cloud CLI、 Google Cloud コンソール、または Terraform（バージョンによって異なります）を使用します。

高度なクラスタから高度なクラスタにアップグレードするには、次の順序で行う必要があります。

  1. 該当する場合は、管理ワークステーションをアップグレードします。
  2. gkectl diagnose cluster を使用して、管理クラスタが正常であることを確認します。問題を解決します。
  3. 管理クラスタをアップグレードします。
  4. gkectl diagnose cluster を使用して、アップグレードが成功し、ユーザー クラスタが正常であることを確認します。問題を解決します。
  5. ユーザー クラスタを一度に 1 つずつアップグレードします。ユーザー クラスタのコントロール プレーンとノードプールは、一緒にアップグレードすることも、個別にアップグレードすることもできます。詳細については、ノードプールをアップグレードするをご覧ください。
  6. gkectl diagnose cluster を使用して、アップグレードが正常に完了したことを確認します。

ユーザー クラスタ内のすべてのノードプールがユーザー クラスタのコントロール プレーンと同じバージョンになると、ユーザー クラスタがアップグレードされ、アップグレードが完了します。

ユーザー クラスタのコントロール プレーンはユーザー クラスタ自体で実行され、ユーザー クラスタのアップグレード中にアップグレードされます。管理クラスタのアップグレード中に、管理クラスタのコントロール プレーン ノードがアップグレードされます。

gkectl diagnose cluster を使用してクラスタを診断する方法については、クラスタを診断するをご覧ください。

高度なクラスタから高度なクラスタへのアップグレードを実行する方法については、クラスタをアップグレードするをご覧ください。

高度なクラスタ以外のクラスタから高度なクラスタにアップグレードする

高度なクラスタ以外のクラスタから高度なクラスタへのアップグレードは、バージョン 1.31、1.32、1.33、1.34 でのみ行われます。これらのバージョンで高度なクラスタ以外のクラスタから高度なクラスタにアップグレードする方法については、アップグレード バージョン ルールをご覧ください。

高度なクラスタ以外のクラスタから高度なクラスタにアップグレードするには、ターゲット バージョンと同じバージョンの gkectl を使用する必要があります（たとえば、バージョン 1.32.0 にアップグレードする場合は、gkectl バージョン 1.32.0 を使用する必要があります）。また、次の順序で操作する必要があります。

  1. 管理ワークステーションとアーティファクトをアップグレードします。
  2. gkectl diagnose cluster を使用して、管理クラスタが正常であることを確認します。問題を解決します。
  3. 管理クラスタをアップグレードします。
  4. gkectl diagnose cluster を使用して、アップグレードが成功し、ユーザー クラスタが正常であることを確認します。問題を解決します。
  5. ユーザー クラスタをアップグレードします。
  6. gkectl diagnose cluster を使用して、アップグレードが正常に完了したことを確認します。

gkectl diagnose cluster を使用してクラスタを診断する方法については、クラスタを診断するをご覧ください。

高度なクラスタ以外のクラスタから高度なクラスタにアップグレードする方法については、高度なクラスタ以外のクラスタから高度なクラスタに更新またはアップグレードするをご覧ください。

高度なクラスタ以外のクラスタから高度なクラスタ以外のクラスタにアップグレードする

バージョン 1.33 以前では、高度なクラスタ以外のクラスタから別の高度なクラスタ以外のクラスタにアップグレードできます。高度なクラスタ以外のクラスタから別の高度なクラスタ以外のクラスタへのアップグレードを許可するバージョンの詳細については、アップグレード バージョン ルールをご覧ください。

高度なクラスタ以外のクラスタをアップグレードする順序は、ターゲット バージョンによって異なります。

  • ターゲット バージョンが 1.31、1.32、1.33 の場合は、ユーザー クラスタをアップグレードする前に管理クラスタをアップグレードする必要があります。
  • ターゲット バージョンが 1.30 以前の場合は、管理クラスタをアップグレードする前に、すべてのユーザー クラスタをアップグレードする必要があります。

バージョン 1.31、1.32、1.33 にアップグレードする

クラスタを高度なクラスタにアップグレードせずにバージョン 1.31、1.32、1.33 にアップグレードするには、次の順序で行う必要があります。

  1. 管理ワークステーションをアップグレードし、バンドル アーティファクトを準備します。
  2. gkectl diagnose cluster を使用して、管理クラスタが正常であることを確認します。問題を解決します。
  3. 管理クラスタをアップグレードします。
  4. gkectl diagnose cluster を使用して、アップグレードが成功し、ユーザー クラスタが正常であることを確認します。問題を解決します。
  5. ユーザー クラスタを一度に 1 つずつアップグレードします。
  6. gkectl diagnose cluster を使用して、アップグレードが正常に完了したことを確認します。

バージョン 1.30 以前にアップグレードする

バージョン 1.30 以前にアップグレードするには、次の順序で行う必要があります。

  1. 管理ワークステーションをアップグレードし、バンドル アーティファクトを準備します。
  2. gkectl diagnose cluster を使用して、ユーザー クラスタが正常であることを確認します。問題を解決します。
  3. すべてのユーザー クラスタを一度に 1 つずつアップグレードします。
  4. gkectl diagnose cluster を使用して、アップグレードが正常に完了し、管理クラスタが正常であることを確認します。問題を解決します。
  5. 管理クラスタをアップグレードします。
  6. gkectl diagnose cluster を使用して、アップグレードが正常に完了したことを確認します。

gkectl diagnose cluster を使用してクラスタを診断する方法については、クラスタを診断するをご覧ください。

高度なクラスタ以外のクラスタから高度なクラスタ以外のクラスタにアップグレードする方法については、高度なクラスタ以外のクラスタをアップグレードしてメンテナンスするをご覧ください。

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

管理クラスタは常に 1 つずつアップグレードします。

ユーザー クラスタをアップグレードする場合は、ユーザー クラスタ全体（コントロール プレーンとクラスタ内のすべてのノードプールを同時に）をアップグレードするか、ユーザー クラスタのコントロール プレーンをアップグレードして、ノードプールを現在のバージョンで残すことができます。どのアプローチを採用するかは、次のような複数の要因によって異なります。

  • クラスタが存在する環境（本番環境または非本番環境）。
  • メンテナンスの時間枠の長さ。
  • ユーザー クラスタのバージョン。

たとえば、開発環境では、プロセスを容易にして、ユーザー クラスタのコントロール プレーンとすべてのノードプールの両方をアップグレードすることをおすすめします。ただし、メンテナンスの時間枠が短い本番環境では、コントロール プレーンのみをアップグレードすることをおすすめします。これは、時間を短縮し、高可用性（HA）のコントロール プレーンを使用することで、コントロール プレーンのアップグレードによるユーザー ワークロードの中断を回避できるためです。

クラスタのアップグレード ツールを選択する

使用するツールは、アップグレードの方法と対象によって異なります。

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

ユーザー クラスタの場合は、次のいずれかのツールを使用してクラスタをアップグレードできます。

  • gkectl コマンドライン ツール（高度なクラスタ以外のクラスタから高度なクラスタへのアップグレードに必要）
  • Terraform（Terraform を使用してユーザー クラスタを作成した場合）
  • Google Cloud コンソール
  • Google Cloud CLI

次の表に、各ツールがサポートするユースケースを示します。

アップグレードのユースケース gkectl gcloud CLI Console Terraform 注意事項と制限事項
管理クラスタをアップグレードする（任意のパス） はい いいえ いいえ × 管理クラスタには常に gkectl が必要です。
非高度なクラスタを高度なクラスタにアップグレードする（変換） はい いいえ いいえ × gkectl のバージョンはターゲット バージョンと一致している必要があります。コントロール プレーン（CP）とノードプールの間のバージョン スキューは許可されません。
非高度なクラスタを非高度なクラスタにアップグレードする（レガシー） はい いいえ いいえ × 1.33 以前でのみ利用可能（オプトアウト パス）。API クライアントはサポートされていません。
ユーザー クラスタをアップグレードする: 高度なクラスタから高度なクラスタ はい はい はい はい1 標準のバージョン スキュー ルールが適用されます。
ユーザー クラスタ全体をアップグレードする（CP とノードプールを一緒に） はい はい はい はい1 高度なユーザー クラスタのすべてのツールでサポートされています。
ユーザー クラスタのコントロール プレーンを個別にアップグレードする（CP のみ） はい はい × はい1 コンソールは、コントロール プレーンのみのアップグレードをサポートしていません。
CP のアップグレード後にノードプールを選択してアップグレードする はい はい × はい1 コンソールでは、個々のノードプールのアップグレードはサポートされていません。
コントロール プレーンと 1 つ以上のノードプールを同時にアップグレードする はい いいえ いいえ × 部分的な同時 CP + ノードプール バージョンのアップグレードは、gkectl でのみサポートされています。

1 Terraform の要件: Terraform を使用してユーザー クラスタをアップグレードできるのは、ユーザー クラスタが Terraform を使用して作成および管理されている場合のみです。

コンソールまたは gcloud CLI を使用して gkectl で作成したクラスタに関する情報を取得するには、GKE On-Prem API にクラスタを登録します。

次のステップ

アップグレード バージョン ルールを確認して、バージョンがアップグレードにどのように影響するかを理解し、使用しているバージョンとアップグレード先のバージョンのバージョン ルールを確認します。

アップグレードのベスト プラクティスで、クラスタのアップグレード プランを作成する