アップグレードのバージョン ルール

現在のバージョンとターゲット バージョンがクラスタのアップグレードにどのように影響するかを理解することで、開始前にバージョン スキュー、アップグレード順序、OS 要件を確認できます。

バージョン固有のアップグレード情報

次の表に、バージョン固有のアップグレード情報を示します。表の後に、特定のリリースに関する詳細が記載されています。バージョンは新しい順に並べ替えられます。クラスタに適用される特定の詳細とルールについては、アップグレード先のバージョンを確認してください。

バージョン	まずアップグレード	コントロール プレーン（CP）のバージョン	ワーカー ノードプールのバージョン	高度なクラスタのステータス	レガシー機能はサポートされていますか？	デフォルトの OS イメージと必須の OS イメージ	Kubeception ノードのアップグレード動作	cert-manager をバンドルしました
1.36	管理クラスタ	1.36、1.35、1.34	1.36、1.35、1.34	必須	なし	ubuntu_cgv2、cos_cgv2	サポート対象外	バンドル
1.35	管理クラスタ	1.35、1.34、1.33	1.35、1.34、1.33	必須	なし	ubuntu_cgv2、cos_cgv2 が必須（cgroup v1 は廃止）	サポート対象外	バンドル
1.34	管理クラスタ	1.34、1.33、1.32	1.34、1.33、1.32	必須（オプトアウトなし、高度な設定以外は自動変換）	なし	ubuntu_cgv2（デフォルト）、cos_cgv2、ubuntu_containerd、cos	サポート対象外	バンドル
1.33	管理クラスタ	1.33、1.32、1.31	1.33、1.32、1.31	デフォルト（自動変換）（1.32 から 1.33 へのオプトアウトのみ）	なし	ubuntu_cgv2（デフォルト）、cos_cgv2、ubuntu_containerd、cos	サポート対象外	高度なクラスタにバンドル
1.32	管理クラスタ	1.32、1.31、1.30	1.32、1.31、1.30	GA（アップグレードをサポート、ノードのアップグレードの分離とスキップをサポート）	なし	ubuntu_cgv2（デフォルト）、cos_cgv2、ubuntu_containerd、cos	サポート対象外（Controlplane V2 に移行する必要があります）	高度なクラスタにバンドル
1.31	管理クラスタ	1.31、1.30、1.29	1.31、1.30、1.29	プレビュー（1.32 へのアップグレードなし、個別またはスキップ ノード アップグレードなし）	はい（Seesaw、F5、Kubeception、非 HA）。推奨機能への移行を強くおすすめします。Dataplane V2 は必須です。	ubuntu_cgv2（デフォルト）、cos_cgv2、ubuntu_containerd、cos	管理ノードは管理クラスタでアップグレードされ、ユーザー CP ノードはユーザー クラスタでアップグレードされます。	バンドルされていない
1.30	ユーザー クラスタ	1.30	1.30、1.29、1.28	利用不可	はい（Seesaw、F5、Kubeception、非 HA）。推奨機能への移行を強くおすすめします。	ubuntu_cgv2（デフォルト）、cos_cgv2、ubuntu_containerd、cos	管理クラスタのアップグレード中に CP ノードと管理ノードがアップグレードされる	バンドルされていない
1.29	ユーザー クラスタ	1.29、1.30	1.29、1.28、1.16	利用不可	はい（Seesaw、F5、Kubeception、非 HA）	ubuntu_cgv2（デフォルト）、cos_cgv2、ubuntu_containerd、cos	管理クラスタのアップグレード中に CP ノードと管理ノードがアップグレードされる	バンドルされていない
1.28	ユーザー クラスタ	1.28、1.29、1.30	1.28、1.16、1.15	利用不可	はい（Seesaw、F5、Kubeception、非 HA）	ubuntu_containerd（デフォルト）、cos、ubuntu_cgv2、cos_cgv2	管理クラスタのアップグレード中に CP ノードと管理ノードがアップグレードされる	バンドルされていない

すべてのバージョンで、ロードバランサ ノードプールのバージョン（enableLoadBalancer: true を含むノードプール）を、ユーザー クラスタのコントロール プレーンと同じバージョンに同時にアップグレードする必要があります。

リリース バージョン別のアップグレード情報

アップグレード先のバージョンにアップグレードするために必要な特定の情報については、アップグレード先のバージョンのセクションをご覧ください。

リリース 1.36

最初にアップグレード: 管理クラスタ

バージョンスキューのルール:

• 1.36 の管理クラスタは、1.36、1.35、1.34 のユーザー クラスタを管理できます。
• ユーザー クラスタのコントロール プレーンのバージョン: 1.36、1.35、1.34。
• ワーカー ノードプールのバージョン: 1.36、1.35、1.34。

高度なクラスタのステータス: 高度なクラスタは必須です。

ノードのアップグレードをスキップする: サポートされています。

レガシー機能のサポート: いいえ。アップグレードをブロックします。

デフォルトの必須 OS イメージ: ubuntu_cgv2、cos_cgv2。新しい構成のデフォルトの osImageType は ubuntu_cgv2 です。

Kubeception ノードのアップグレード動作: サポートされていません。アップグレードをブロックします。

アップグレード ツール:

• gkectl: 管理クラスタに必要です。サポートされているバージョンは 1.36、1.37、1.38 です。
• Terraform: Terraform を使用してユーザー クラスタを作成した場合にサポートされます。
• Google Cloud コンソール: ユーザー クラスタのアップグレードでサポートされています。
• Google Cloud CLI: ユーザー クラスタのアップグレードでサポートされています。

その他の要件:

• 管理クラスタのアップグレードは、gkectl upgrade admin --async を使用して非同期で実行できます。

リリース 1.35

最初にアップグレード: 管理クラスタ

バージョンスキューのルール:

• 1.35 の管理クラスタは、1.35、1.34、1.33 のユーザー クラスタを管理できます。
• ユーザー クラスタのコントロール プレーンのバージョン: 1.35、1.34、1.33。
• ワーカー ノードプールのバージョン: 1.35、1.34、1.33。

高度なクラスタのステータス: 高度なクラスタは必須です。

ノードのアップグレードをスキップする: サポートされています。

レガシー機能のサポート: いいえ。アップグレードをブロックします。

デフォルトの必須 OS イメージ: ubuntu_cgv2、cos_cgv2 は必須（cgroup v1 は廃止）。新しい構成のデフォルトの osImageType は ubuntu_cgv2 です。アップグレードする前に、クラスタを cgroup v2 に移行する必要があります。

Kubeception ノードのアップグレード動作: サポートされていません。アップグレードをブロックします。

アップグレード ツール:

• gkectl: 管理クラスタに必要です。サポートされているバージョンは 1.35、1.36、1.37 です。
• Terraform: Terraform を使用してユーザー クラスタを作成した場合にサポートされます。
• コンソール: ユーザー クラスタのアップグレードでサポートされています。
• gcloud CLI: ユーザー クラスタのアップグレードでサポートされています。

その他の要件:

• 管理クラスタのアップグレードは、gkectl upgrade admin --async を使用して非同期で実行できます。

リリース 1.34

最初にアップグレード: 管理クラスタ

バージョンスキューのルール:

• 1.34 の管理クラスタは、1.34、1.33、1.32 のユーザー クラスタを管理できます。
• ユーザー クラスタのコントロール プレーンのバージョン: 1.34、1.33、1.32。

• ワーカー ノードプールのバージョン: 1.34、1.33、1.32。

  注: 高度なクラスタ以外のクラスタを高度なクラスタに変換する場合、バージョンの不一致は許可されません。コントロール プレーンとすべてのノードプールを同時にアップグレードする必要があります。

高度なクラスタのステータス: 高度なクラスタは必須です。

ノードのアップグレードをスキップする: サポートされています。

レガシー機能のサポート: いいえ。アップグレードをブロックします。

デフォルトの必須 OS イメージ: ubuntu_cgv2、cos_cgv2、ubuntu_containerd、cos。デフォルトの osImageType は ubuntu_cgv2 です。

Kubeception ノードのアップグレード動作: サポートされていません。アップグレードをブロックします。

アップグレード ツール:

• gkectl: 管理クラスタに必要です。高度なクラスタ以外のクラスタを高度なクラスタに変換するために必要です（1.34 では必須。gkectl バイナリ バージョンはターゲット リリース バージョンと完全に一致する必要があります）。サポートされているバージョンは 1.34、1.35、1.36 です。
• Terraform: Terraform を使用してユーザー クラスタを作成した場合にサポートされます。
• コンソール: 高度なユーザー クラスタのアップグレードでサポートされています。
• gcloud CLI: 高度なユーザー クラスタのアップグレードでサポートされています。

その他の要件:

バージョン 1.34 へのアップグレードには、次の追加要件が適用されます。

• 1.34 にアップグレードすると、高度なクラスタ以外のクラスタは自動的に高度なクラスタに変換されます。高度なクラスタ以外のクラスタから高度なクラスタへのアップグレードに関する特定のルールについては、クラスタを更新または高度なクラスタにアップグレードするをご覧ください。

• バンドルされた cert-manager は必須であり、バージョン 1.19 に更新され、既存のカスタム cert-manager インストールをオーバーライドします。バンドルされた cert-manager へのアップグレードの詳細については、バンドルされた cert-manager を使用するをご覧ください。

• ノード コンテナ ランタイムが containerd 2.0 にアップグレードされました。その結果、以下の影響が生じることが考えられます。

  • containerd 2.0 は、以前の Docker イメージ Manifest V2 またはスキーマ 1 イメージをサポートしていません。1.34 にアップグレードする前に、ワークロードが Docker スキーマ 2 または OCI 準拠の形式を使用してコンテナ イメージを pull していることを確認してください。
  • レジストリ ミラー構成は、containerd 2.0 の hosts.toml 形式に移行されます。ノードでカスタム ミラー構成またはエアギャップのあるレジストリ エンドポイントを直接管理する場合は、構成が hosts.toml と一致していることを確認します。
  • /etc/containerd/config.toml にパッチを適用するカスタム DaemonSet またはスクリプトを使用している場合は、非推奨の containerd v1 構成オプションが使用されていないことを確認してください。これらのオプションを使用すると、containerd 2.0 で containerd の起動に失敗する可能性があります。

• nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate フィールドのデフォルト値がバージョン 1.34.300 で変更されました。バージョン 1.34.300 以降でノードプールを順次アップグレードする場合は、ユーザー クラスタの構成ファイルで nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate: 1 を設定します。

  • バージョン 1.34.0 ～ 1.34.200 の場合、nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate のデフォルトは 1 で、一度に 1 つのノードプールを順番に更新します。
  • バージョン 1.34.300 以降では、nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate のデフォルトは 0 で、すべてのノードプールが同時に更新されます。

  詳細については、ノードプールの更新ポリシーを構成するをご覧ください。

• アップグレードのプリフライト チェックでは、クラスタ全体のすべての PodDisruptionBudget（PDB）構成がアクティブに検証されます。アップグレードする前に、ワークロードに過度に制限的な PDB（maxUnavailable: 0 や minAvailable と一致する合計レプリカなど）がないことを確認してください。このような PDB があると、ノードのドレインがブロックされたり、プリフライト チェックが失敗したりする可能性があります。

• アップグレードが中断された場合は、バージョン 1.34.300-gke.59 以降に直接アップグレードします。このバージョンでは、障害発生後に gkectl upgrade admin を再実行する必要がある場合に、ブートストラップ クラスタが削除されなくなります。詳細については、gkectl upgrade admin を再実行するとブートストラップ クラスタが削除されるをご覧ください。

• 高度なクラスタでは、gkectl upgrade admin --async を使用して管理クラスタのアップグレードを非同期で実行できます。ただし、高度なクラスタ以外のクラスタから高度なクラスタに変換する場合は除きます。

リリース 1.33

最初にアップグレード: 管理クラスタ

バージョンスキューのルール:

• 1.33 の管理クラスタは、1.33、1.32、1.31 のユーザー クラスタを管理できます。
• ユーザー クラスタのコントロール プレーンのバージョン: 1.33、1.32、1.31。

• ワーカー ノードプールのバージョン: 1.33、1.32、1.31。

  注: 高度なクラスタ以外のクラスタを高度なクラスタに変換する場合、バージョンの不一致は許可されません。コントロール プレーンとすべてのノードプールを同時にアップグレードする必要があります。

高度なクラスタのステータス: 高度なクラスタはデフォルトのクラスタタイプであり、自動的に変換されます。オプトアウトが許可されています。詳細については、高度なクラスタ以外のクラスタをアップグレードして維持するをご覧ください。enableAdvancedCluster を false に設定すると、新しいクラスタの作成は失敗します。

ノードのアップグレードをスキップする: サポートされています。

レガシー機能のサポート: いいえ。アップグレードをブロックします。

デフォルトの必須 OS イメージ: ubuntu_cgv2、cos_cgv2、ubuntu_containerd、cos。デフォルトの osImageType は ubuntu_cgv2 です。

Kubeception ノードのアップグレード動作: サポートされていません。アップグレードをブロックします。

アップグレード ツール:

• gkectl: 高度なクラスタ以外のクラスタを高度なクラスタに変換するために必要です（gkectl バイナリ バージョンはターゲット リリース バージョンと完全に一致する必要があります）。管理クラスタに必要です。サポートされているバージョンは 1.33、1.34、1.35 です。
• Terraform: Terraform を使用してユーザー クラスタを作成した場合にサポートされます。
• コンソール: 高度なユーザー クラスタのアップグレードでサポートされています。
• gcloud CLI: 高度なユーザー クラスタのアップグレードでサポートされています。

その他の要件:

バージョン 1.33 へのアップグレードには、次の追加要件が適用されます。

• 1.32 から 1.33 へのアップグレードでは、デフォルトで高度なクラスタ以外のクラスタが高度なクラスタに自動的に変換されます。クラスタを高度なクラスタ以外の状態に維持できます。クラスタを高度なクラスタ以外の状態に維持する方法については、高度なクラスタ以外のクラスタをアップグレードして維持するをご覧ください。

• 高度なクラスタは、cert-manager v1.18 を自動的にインストールしてバンドルし、既存のカスタム cert-manager インストールをオーバーライドします。バンドルされた cert-manager へのアップグレードの詳細については、バンドルされた cert-manager を使用するをご覧ください。

• このリリースで高度なクラスタにアップグレードする場合、高度なクラスタ以外のクラスタから高度なクラスタに変換するときに、gkectl バイナリ バージョンがターゲット リリース バージョンと完全に一致している必要があります。この要件は、高度なクラスタへのアップグレード中にのみ適用されます。高度なクラスタの他のすべてのアップグレードでは、標準のバージョン スキュー ルールが有効になります。

• アップグレードが中断された場合は、バージョン 1.33.700-gke.71 以降に直接アップグレードします。このバージョンでは、障害発生後に gkectl upgrade admin を再実行する必要がある場合に、ブートストラップ クラスタが削除されないようにします。

• すべてのユーザー クラスタで Controlplane V2 が実行されている場合は、高度なクラスタと高度な HA 以外のクラスタに対して gkectl upgrade admin --async を使用して、管理クラスタのアップグレードを非同期で実行できます。高度なクラスタ以外のクラスタから高度なクラスタに変換する場合は、--async フラグを使用できません。

リリース 1.32

最初にアップグレード: 管理クラスタ

バージョンスキューのルール:

• 1.32 の管理クラスタは、1.32、1.31、1.30 のユーザー クラスタを管理できます。
• ユーザー クラスタのコントロール プレーンのバージョン: 1.32、1.31、1.30。

• ワーカー ノードプールのバージョン: 1.32、1.31、1.30。

  注: 高度なクラスタ以外のクラスタを高度なクラスタに変換する場合、バージョンの不一致は許可されません。コントロール プレーンとすべてのノードプールを同時にアップグレードする必要があります。

高度なクラスタのステータス: サポートされています。

ノードのアップグレードをスキップする: サポートされています。

レガシー機能のサポート: いいえ。アップグレードをブロックします。

デフォルトの必須 OS イメージ: ubuntu_cgv2、cos_cgv2、ubuntu_containerd、cos。デフォルトの osImageType は ubuntu_cgv2 です。

Kubeception ノードのアップグレード動作: サポートされていません。アップグレードをブロックします。Controlplane V2 に移行する必要があります。

アップグレード ツール:

• gkectl: 高度なクラスタ以外のクラスタを高度なクラスタに変換するために必要です（gkectl バイナリ バージョンはターゲット リリース バージョンと完全に一致する必要があります）。管理クラスタに必要です。サポートされているバージョンは 1.32、1.33、1.34 です。
• Terraform: Terraform を使用してユーザー クラスタを作成した場合にサポートされます。
• コンソール: 高度なユーザー クラスタのアップグレードでサポートされています。
• gcloud CLI: 高度なユーザー クラスタのアップグレードでサポートされています。

その他の要件:

バージョン 1.32 へのアップグレードには、次の追加要件が適用されます。

• これは、完全にサポートされている GA の高度なクラスタへのオプションのアップグレードを可能にする最初のバージョンです。以下からオプションを選ぶことができます。

  • 高度なクラスタ以外のクラスタにアップグレードし、高度なクラスタ以外のクラスタを維持します。このオプションを選択すると、このリリース以降、次の操作を行うことができます。

    • ユーザー クラスタのコントロール プレーンとワーカー ノードプールを個別にアップグレードします。ワーカー ノードプールは、コントロール プレーンより最大 2 つ前のマイナー バージョンにできます。
    • 管理クラスタとユーザー クラスタのアップグレードを非同期で実行します。

  • 高度なクラスタ以外のクラスタにアップグレードしてから、高度なクラスタ以外のクラスタを高度なクラスタに変換します。このオプションを選択すると、このリリース以降、次の操作を行うことができます。

    • 高度なクラスタ以外のクラスタをアップグレードする場合は、ユーザー クラスタのコントロール プレーンとワーカー ノードプールを個別にアップグレードします。ただし、高度なクラスタに変換する場合は、個別にアップグレードしないでください。ワーカー ノードプールは、コントロール プレーンより最大 2 つ前のマイナー バージョンにできます。
    • 高度なクラスタ以外のクラスタをアップグレードする場合は、管理クラスタとユーザー クラスタのアップグレードを非同期で実行します。
    • 高度なクラスタに変換する場合は、リリース バージョン 1.32.1000-gke.57 以降にアップグレードします。このバージョンには、ブートストラップ クラスタが削除されない既知の問題の修正が含まれています。

  • 高度なクラスタに直接アップグレードします。このオプションを選択すると、このリリース以降、次のようになります。

    • コントロール プレーンとすべてのノードプールを一緒にアップグレードする必要があります。
    • ユーザー クラスタのアップグレードは非同期で実行できますが、管理クラスタのアップグレードは非同期で実行できません。
    • リリース バージョン 1.32.1000-gke.57 以降にアップグレードします。このバージョンには、ブートストラップ クラスタが削除されない既知の問題の修正が組み込まれています。

• このバージョン以降、次のレガシー機能はサポートされません。詳細については、レガシー機能をご覧ください。

  • Dataplane V1（Calico）。1.32 にアップグレードする前に、Dataplane V2 にアップグレードします。
  • Seesaw。1.32 にアップグレードする前に、代替ロードバランサにアップグレードします。
  • 統合型 F5 BIG-IP。1.32 にアップグレードする前に、代替ロードバランサにアップグレードします。
  • Kubeception。1.32 にアップグレードする前に、Kubeception 以外のクラスタにアップグレードします。
  • 非 HA 管理クラスタ。1.32 にアップグレードする前に、HA 管理クラスタにアップグレードします。

• 高度なクラスタ以外のクラスタから高度なクラスタに変換する場合は、gkectl バイナリ バージョンがターゲット リリース バージョンと完全に一致している必要があります。この要件は、高度なクラスタへのアップグレード中にのみ適用されます。高度なクラスタの他のすべてのアップグレードでは、標準のバージョン スキュー ルールが有効になります。

• アップグレードが中断された場合は、バージョン 1.32.1000-gke.57 以降に直接アップグレードします。このバージョンでは、障害発生後に gkectl upgrade admin を再実行する必要がある場合に、ブートストラップ クラスタが削除されないようにします。

• バージョン 1.32 以降では、すべてのユーザー クラスタで Controlplane V2 が実行されている場合、高度なクラスタと高度でない HA クラスタに対して gkectl upgrade admin --async を使用して管理クラスタのアップグレードを非同期で実行できます。高度なクラスタ以外のクラスタから高度なクラスタに変換する場合は、--async フラグを使用できません。

リリース 1.31

最初にアップグレード: 管理クラスタ

バージョンスキューのルール:

• 1.31 の管理クラスタは、1.31、1.30、1.29 のユーザー クラスタを管理できます。
• ユーザー クラスタのコントロール プレーンのバージョン: 1.31、1.30、1.29。
• ワーカー ノードプールのバージョン: 1.31、1.30、1.29。（1.31 の高度なクラスタではサポートされていません）。
• 1.29 / 1.30 から 1.31 にアップグレードするには、管理クラスタを 1.31 にアップグレードする前に、すべてのクラスタをバージョン 1.30 にアップグレードする必要があります。

高度なクラスタのステータス: プレビューのみ。上位バージョンにアップグレードできない。

ノードのアップグレードをスキップする: サポートされています。

サポートされているレガシー機能: Dataplane V2 は必須。Kubeception、Seesaw、F5 は引き続きサポートされます。

デフォルトの必須 OS イメージ: ubuntu_cgv2、cos_cgv2、ubuntu_containerd、cos。デフォルトの osImageType は ubuntu_cgv2 です。

Kubeception ノードのアップグレード動作: 管理ノードは管理クラスタとともにアップグレードされます。ユーザー CP ノードはユーザー クラスタとともにアップグレードされます。

アップグレード ツール:

• gkectl: 管理クラスタ、非高度なクラスタ、高度なクラスタ（このリリースのプレビュー）に必要です。サポートされているバージョンは 1.31、1.32、1.33 です。
• Terraform: Terraform を使用してユーザー クラスタを作成した場合は、登録済みのユーザー クラスタでサポートされます。
• コンソール: 登録済みのユーザー クラスタのアップグレードでサポートされています。
• gcloud CLI: 登録済みのユーザー クラスタのアップグレードでサポートされています。

その他の要件:

バージョン 1.31 へのアップグレードには、次の追加要件が適用されます。

• このリリースでは、プレビュー モードで高度なクラスタが導入されました。このリリースでは、高度なクラスタ以外のクラスタを高度なクラスタに移行することはできません。新しいクラスタを高度なクラスタとして作成できますが、これらのプレビュー バージョンの高度なクラスタを上位バージョンにアップグレードすることはできません。このリリースでは、高度なクラスタを作成することはおすすめしません。プレビューなどのプロダクトのリリース ステージの詳細については、プロダクトのリリース ステージをご覧ください。

• 1.31 以降では、アップグレードのアーキテクチャが、管理クラスタがユーザー クラスタ以上である必要があるモデルに変更されました。以前は、ユーザー クラスタは管理クラスタより 2 つ前のマイナー バージョンまで使用できました。

• 管理クラスタによって管理されているユーザー クラスタをアップグレードする前に、管理クラスタをアップグレードする必要があります。管理クラスタは、同じマイナー バージョンまたは 2 つ前のマイナー バージョンまでのユーザー クラスタを管理できます。たとえば、バージョン 1.31 の管理クラスタは、バージョン 1.31、1.30、1.29 のユーザー クラスタを管理できます。

• 1.29 から 1.31 にアップグレードするには、中間ステップとして 1.30 バンドルをステージングする必要があります。1.31 にアップグレードするには、管理ワークステーションに 1.30 と 1.31 の両方のバンドルをダウンロードする必要があります。1.29 から 1.31 へのバージョン スキップ アップグレードを実行する手順は次のとおりです。

  1. ユーザー クラスタのコントロール プレーンのみを 1.29 から 1.30 にアップグレードします（ワーカー ノードプールは 1.29 のままにします）。
  2. 管理クラスタを 1.29 から 1.30 にアップグレードします。
  3. 管理クラスタを 1.30 からターゲットの 1.31 にアップグレードします。
  4. ユーザー クラスタのコントロール プレーンとワーカー ノードプールを 1.31 にアップグレードします。

• Kubeception を使用している場合、管理クラスタのノードは管理クラスタのアップグレード中にアップグレードされ、ユーザー クラスタのコントロール プレーン ノードはユーザー クラスタのアップグレード中にアップグレードされます。

• 1.31 にアップグレードするには、Dataplane V2 を有効にする必要があります。CNI の移行中にネットワーク ポリシーの競合とトラフィックのドロップを防ぐには、すべての NetworkPolicy オブジェクトを手動で保存して削除し、アップグレード後に復元する必要があります。Dataplane V2 に移行する手順は次のとおりです。

  1. すべてのカスタム ネットワーク ポリシーをエクスポートして保存します。

     kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
         get networkpolicy -A -o wide \
         --field-selector metadata.namespace!=kube-system
     kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
         get networkpolicy POLICY_NAME \
         -n NAMESPACE -o yaml > policy.yaml
     

     次のように置き換えます。

     • USER_CLUSTER_KUBECONFIG: ユーザー クラスタの kubeconfig ファイルのパス
     • POLICY_NAME: NetworkPolicy オブジェクトの名前。
     • NAMESPACE: NetworkPolicy オブジェクトの Namespace。

  2. クラスタからネットワーク ポリシーを削除します。

     kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
         delete networkpolicy POLICY_NAME \
         -n NAMESPACE
     

  3. ユーザー クラスタの構成ファイルで enableDataplaneV2: true を設定し、1.31 へのアップグレードを実行します。

  4. 1.31 へのアップグレードが完了したら、保存したポリシーを適用して、Cilium がポリシーを拡張 Berkeley Packet Filter（eBPF）にクリーンにコンパイルするようにします。

     kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
         apply -f policy.yaml
     

• HA 管理クラスタがあり、すべてのユーザー クラスタで Controlplane V2 が実行されている場合は、gkectl upgrade admin --async コマンドを使用してアップグレードを非同期で実行できます。

• すべてのユーザー クラスタに Dataplane V2 が必要です。ユーザー クラスタをバージョン 1.31 にアップグレードする前に、Dataplane V2 を有効にするの手順に沿って操作します。

• レガシー機能は 1.32 ではサポートされていません。1.30 と 1.31 で置き換えることで、1.32 へのアップグレード時の問題を回避できます。

リリース 1.30

最初にアップグレード: ユーザー クラスタ

バージョンスキューのルール:

• 1.30 のユーザー クラスタは、1.30、1.29、1.28 の管理クラスタで管理できます。
• 1.30 の管理クラスタは、1.30 のユーザー クラスタのみを管理できます。管理クラスタを 1.31 にアップグレードする前に、すべてのユーザー クラスタと管理クラスタを 1.30 にアップグレードする必要があります。また、ユーザー クラスタを 1.31 にアップグレードする前に、管理クラスタを 1.31 にアップグレードする必要があります。
• ユーザー クラスタのコントロール プレーンのバージョン: 1.30。
• ワーカー ノードプールのバージョン: 1.30、1.29、1.28。

高度なクラスタのステータス: 使用不可。

ノードのアップグレードをスキップする: サポートされています。

レガシー機能のサポート: サポートされています。推奨機能への移行を強くおすすめします。

デフォルトの必須 OS イメージ: ubuntu_cgv2、cos_cgv2、ubuntu_containerd、cos。デフォルトの osImageType は ubuntu_cgv2 です。

• Kubeception ノードのアップグレード動作:** コントロール プレーン ノードと管理ノードは、管理クラスタのアップグレード中にアップグレードされます。

アップグレード ツール:

• gkectl: 管理クラスタに必要です。サポートされているバージョンは 1.30、1.31、1.32 です。
• Terraform: Terraform を使用してユーザー クラスタを作成した場合は、登録済みのユーザー クラスタでサポートされます。
• コンソール: 登録済みのユーザー クラスタのアップグレードでサポートされています。
• gcloud CLI: 登録済みのユーザー クラスタのアップグレードでサポートされています。

その他の要件:

バージョン 1.30 へのアップグレードには、次の追加要件が適用されます。

• このバージョンと以前のすべてのバージョンでは、管理クラスタをアップグレードする前に、すべてのユーザー クラスタを移行する必要があります。管理クラスタは、管理対象のユーザー クラスタと同じか、それより低いマイナー バージョンにする必要があります。

• Kubeception を使用する場合、アップグレード中に次の処理が行われます。

  1. ユーザー クラスタをアップグレードします。ユーザー コントロール プレーンは管理クラスタ内に存在するため、gkectl upgrade cluster を実行するとワーカー ノードプールのみがアップグレードされます。
  2. 管理クラスタをアップグレードします。管理クラスタのアップグレードでは、管理ノードがアップグレードされ、すべてのユーザー クラスタのコントロール プレーンが同時に自動的にアップグレードされます。

• Controlplane V2 を使用している場合、アップグレード中に次の処理が行われます。

  1. ユーザー クラスタをアップグレードします。これにより、コントロール プレーンとワーカーノード プールがアップグレードされます。
  2. 管理クラスタをアップグレードします。これにより、管理ノードがアップグレードされます。

• 新しいユーザー クラスタを作成するときは、このリリース以降、enableControlplaneV2 フィールドをデフォルトの true に設定する必要があります。enableControlplaneV2 フィールドを false に設定すると、gkectl はファイルを拒否し、クラスタを作成しません。

• HA 管理クラスタがあり、すべてのユーザー クラスタで Controlplane V2 が実行されている場合は、gkectl upgrade admin --async コマンドを使用してアップグレードを非同期で実行できます。

• レガシー機能は 1.32 ではサポートされていません。1.30 と 1.31 で置き換えることで、1.32 へのアップグレード時の問題を回避できます。

リリース 1.29

最初にアップグレード: ユーザー クラスタ

バージョンスキューのルール:

• 1.29 のユーザー クラスタは、1.29、1.28、1.16 の管理クラスタで管理できます。
• 1.29 の管理クラスタは、1.29 と 1.30 のユーザー クラスタを管理できます。1.29 の管理クラスタは 1.31 のユーザー クラスタを管理できません。これは、すべてのクラスタが最初に 1.30 に到達する必要があり、ユーザー クラスタを 1.31 にアップグレードする前に管理クラスタを 1.31 にアップグレードする必要があるためです。
• ユーザー クラスタのコントロール プレーンのバージョン: 1.29 または 1.30（最大 1 つ後のマイナー バージョン）。
• ワーカー ノードプールのバージョン: 1.29、1.28、1.16。

高度なクラスタのステータス: 使用不可。

ノードのアップグレードをスキップする: サポートされています。

レガシー機能のサポート: サポートされています。

デフォルトの必須 OS イメージ: ubuntu_cgv2、cos_cgv2、ubuntu_containerd、cos。デフォルトの osImageType は ubuntu_cgv2 です。

Kubeception ノードのアップグレード動作: 管理クラスタのアップグレード中にコントロール プレーンと管理ノードがアップグレードされます。

アップグレード ツール:

• gkectl: 管理クラスタに必要です。サポートされているバージョンは 1.29、1.30、1.31 です。
• Terraform: Terraform を使用してユーザー クラスタを作成した場合は、登録済みのユーザー クラスタでサポートされます。
• コンソール: 登録済みのユーザー クラスタのアップグレードでサポートされています。
• gcloud CLI: 登録済みのユーザー クラスタのアップグレードでサポートされています。

その他の要件:

バージョン 1.29 へのアップグレードには、次の追加要件が適用されます。

• ワーカーノードは、コントロール プレーンより最大 2 つ前のマイナー バージョン（n+2）まで許容されます。
• ワーカー ノードプールをアップグレードするときに、マイナー バージョンをスキップできます。たとえば、ワーカー ノードプールを 1.28 から 1.30 にアップグレードできます。
• プリフライト チェックは、管理ワークステーションではなく、管理クラスタまたは一時的なブートストラップ kind クラスタ内の Pod として実行されます。
• このバージョン以降では、gkectl upgrade cluster --dry-run を使用してクラスタをアップグレードせずにプリフライト チェックを実行できます。
• HA 管理クラスタがあり、すべてのユーザー クラスタで Controlplane V2 が実行されている場合は、gkectl upgrade admin --async コマンドを使用してアップグレードを非同期で実行できます。

リリース 1.28

最初にアップグレード: ユーザー クラスタ

バージョンスキューのルール:

• 1.28 のユーザー クラスタは、1.28、1.16、1.15 の管理クラスタで管理できます。
• 1.28 の管理クラスタは、1.28、1.29、1.30 のユーザー クラスタを管理できます。
• ユーザー クラスタのコントロール プレーンのバージョン: 1.28、1.29、1.30（最大 2 つ後のマイナー バージョン）。
• ワーカー ノードプールのバージョン: 1.28、1.16、1.15（最大 2 つ低いマイナー バージョン）。

高度なクラスタのステータス: 使用不可。

ノードのアップグレードをスキップする: サポートされています。

レガシー機能のサポート: サポートされています。

デフォルトの必須 OS イメージ: ubuntu_containerd、cos、ubuntu_cgv2、cos_cgv2。デフォルトの osImageType は ubuntu_containerd です。

Kubeception ノードのアップグレード動作: 管理クラスタのアップグレード中にコントロール プレーン ノードと管理ノードがアップグレードされます。

アップグレード ツール:

• gkectl: 管理クラスタに必要です。サポートされているバージョンは 1.28、1.29、1.30 です。
• Terraform: Terraform を使用してユーザー クラスタを作成した場合は、登録済みのユーザー クラスタでサポートされます。
• コンソール: 登録済みのユーザー クラスタのアップグレードでサポートされています。
• gcloud CLI: 登録済みのユーザー クラスタのアップグレードでサポートされています。

その他の要件:

バージョン 1.28 へのアップグレードには、次の追加要件が適用されます。

• kubernetesmetadata.googleapis.com を有効にして、logging-monitoring サービス アカウントに roles/kubernetesmetadata.publisher を付与する必要があります。そうしないと、プリフライト チェックが失敗するか、403 PERMISSION_DENIED エラーが表示されることがあります。API を有効にして、既存の logging-monitoring サービス アカウントにロールを付与します。

  gcloud services enable kubernetesmetadata.googleapis.com
  gcloud projects add-iam-policy-binding PROJECT_ID \
      --member="serviceAccount:LOGGING_SA" \
      --role="roles/kubernetesmetadata.publisher"
  

  次のように置き換えます。

  • PROJECT_ID: ユーザー クラスタがメンバーであるフリート ホスト プロジェクトの ID。
  • LOGGING_SA: logging-monitoring サービス アカウントのメールアドレス。

• ノードプールのアップグレード中にバージョンをスキップすることは技術的には可能ですが、この機能はプレビュー機能として導入されたものであり、このバージョンではおすすめしません。プレビューなどのプロダクトのリリース ステージの詳細については、プロダクトのリリース ステージをご覧ください。

• バンドルされたロードバランサを使用するノードプールは、クラスタ バージョンと完全に一致する必要があります。

• nodePools[i].updateStrategy.rollingUpdate.maxSurge フィールドを設定すると、複数のノードを同時にアップグレードできます。vSphere クラスタには、アップグレード中に追加のサージ VM に対応するのに十分な CPU、RAM、使用可能な IP アドレスが必要です。

  • maxSurge: 1（デフォルト）に設定すると、ノードが 1 つずつアップグレードされます（ドレイン、置換、検証、繰り返しの順）。
  • maxSurge: N（N > 1）を設定して、最大 N 個のワーカーノードを同時にプロビジョニングしてドレインします（たとえば、maxSurge: 3 は 3 つのワーカーノードを同時にアップグレードします）。

• 管理ワークステーションをアップグレードするには、管理ワークステーションに 100 GB 以上の空きディスク容量が必要です。

• アップグレードに使用する gkectl のバージョンは、現在のクラスタより 2 つ前のマイナー バージョンまで使用できます。これより低いマイナー バージョンは使用できません。

1.28 より前のリリース

バージョン 1.28 より前のリリースにアップグレードする場合は、次の追加要件が適用されます。1.16 と 1.28 の間にリリース バージョンはありません。

リリース 1.16:

• 管理クラスタとユーザー クラスタ間、およびコントロール プレーンとノードプール間のバージョン スキューは、1 つのマイナー バージョンのみです。たとえば、1.15 の管理クラスタは、バージョン 1.15 または 1.16 のユーザー クラスタのみを管理できます。1.16 にアップグレードされたユーザー クラスタのコントロール プレーンは、バージョン 1.15 または 1.16 を実行しているワーカー ノードプールを管理できます。バージョン 1.14 のプールは、コントロール プレーンをバージョン 1.16 に移行する前に 1.15 にアップグレードする必要があります。バージョン スキューの詳細については、バージョン スキューのルールをご覧ください。
• クラスタは、作成時または 1.16 へのアップグレード時に GKE On-Prem API に自動的に登録されます。この変更により、管理ワークステーションのシェルだけでなく、コンソール、gcloud CLI、Terraform を使用して、ユーザー クラスタの表示、モニタリング、アップグレードを行うことができます。

リリース 1.14:

• 最初にユーザー クラスタのコントロール プレーンのみをアップグレードできるため、すべてのワーカー ノードプールを同時にドレインしてアップグレードする必要はありません。
• アップグレード中、システムはワークステーション上の既存の管理クラスタとユーザー クラスタの kubeconfig ファイルを自動的に検査して更新し、認証情報を自動的に更新します。

リリース 1.13:

• このバージョンより前は、オフラインの管理クラスタを使用できました。このリリースでは、管理クラスタを Google Cloudに登録する必要があります。クラスタの登録方法については、既存のクラスタを登録するをご覧ください。
• クラスタを Google Distributed Cloud ソフトウェアのみ（VMware バージョン 1.13 以降）にアップグレードするには、まず、Docker Engine を使用しているユーザー クラスタ ノードプールを containerd に更新する必要があります。

バンドルされた cert-manager を使用する

バンドルされた cert-manager を使用する必要があります。これは、高度なクラスタに自動的にインストールされます。高度なクラスタ以外のクラスタから高度なクラスタに移行すると、統合された cert-manager は、お客様がインストールした cert-manager のバージョンを自動的にオーバーライドします。高度なクラスタに更新またはアップグレードする前に、既存の cert-manager に重要なカスタム構成や機能が適用されていないことを確認してください。

重要なカスタム構成または機能を cert-manager に適用したかどうかを確認するには、次の操作を行います。

• 継続的デプロイ ツールを一時停止します。GitOps ツール（Config Sync、ArgoCD、Flux など）を使用して cert-manager を管理している場合は、アップグレードする前に同期を一時停止するか、リポジトリから cert-manager マニフェストを削除します。クラスタのアップグレード中に GitOps コントローラが cert-manager を古いバージョンまたはカスタム マニフェストに調整しようとすると、調整ループが作成され、クラスタのアップグレードが停止する可能性があります。
• アップグレード前に、cert-manager Pod、Namespace、CRD を手動でアンインストールまたは削除しないでください。gkectl は、これらのアップグレードをインプレースで管理します。
• cert-manager デプロイ フラグ、ノードセレクタ、Pod リソースの上限を変更した場合は、元に戻します。高度なクラスタは、cert-manager でのカスタム バイナリ引数またはデプロイレベルのオーバーライドをサポートしていません。
• 特殊な外部発行者、プライベート ACME DNS-01 Webhook プラグイン、カスタム Webhook を使用する場合は、アップグレード先のリリースにバンドルされている cert-manager バージョンとサードパーティ プラグインに互換性があることを確認します。

詳細については、高度なクラスタにバンドルされている cert-manager にアップグレードするをご覧ください。

次の表に、バンドルされた cert-manager が必要なリリース バージョンを示します。

バージョン	新しいクラスタのステータス	既存のクラスタのアップグレードのステータス	バンドルされた cert-manager が必要ですか？
1.34+	必須	必須の変換（v1.19 バンドル）	すべてのお客様に必須です。高度なクラスタ以外のクラスタは存在できなくなります。
1.33	Standard / すべての新しいクラスタのデフォルト	デフォルトで高度なクラスタに自動変換（v1.18 バンドル）	enableAdvancedCluster: false を使用して明示的にオプトアウトしない限り、ほぼすべてのクラスタで必須です（1.32 → 1.33 のみ）。
1.32（GA）	デフォルトで有効	高度なクラスタへの変換（省略可）	高度なクラスタが有効になっている場合は必須です。
1.31（プレビュー）	省略可（enableAdvancedCluster: true）	非対応	高度なクラスタが有効になっている場合は必須です。

サポートされている各リリースにバンドルされている cert-manager バージョンを確認するには、バンドルされている cert-manager バージョンをご覧ください。

コントロール プレーン V2

Controlplane V2 が有効になっている場合、ユーザー クラスタのコントロール プレーンはユーザー クラスタ自体で実行されます。Controlplane V2 の場合、ユーザー クラスタのコントロール プレーン ノードはユーザー クラスタのアップグレード中にアップグレードされ、管理クラスタのコントロール プレーン ノードは管理クラスタのアップグレード中にアップグレードされます。

従来の機能

次の表に、バージョン 1.32 以降でブロックされるレガシー機能を示します。これらの機能を使用している場合は、バージョン 1.32 以降にアップグレードする前に、推奨される代替機能に移行する必要があります。

| レガシー機能（1.32 でブロック） | 置換（推奨） | 移行手順へのリンク | | --- | --- | --- | | Dataplane V1（Calico） | Dataplane V2（Cilium / eBPF） | Dataplane V2 に移行する| | Kubeception | Controlplane V2 | Controlplane V2 に移行する | | 非 HA 管理クラスタ（1 レプリカ） | HA 管理クラスタ（3 レプリカ） | HA 管理クラスタに移行する | | Seesaw ロードバランサ | MetalLB または ManualLB | MetalLB に移行するまたはロードバランサ タイプを移行する| | 統合 F5 BIG-IP（loadBalancer.kind: "F5BigIP"） | ManualLB（F5 Big-IP Controller または CCGI とペア設定） | ManualLB に移行する |

レガシー機能から推奨機能に移行する方法については、推奨機能へのクラスタの移行を計画するをご覧ください。

Kubeception の移行とバージョンの動作

Kubeception は、バージョン 1.32 以降にアップグレードする前に Controlplane V2 に移行する必要があるレガシー機能です。

Kubeception を使用するクラスタのアップグレードは、バージョンによって動作が異なります。

• 1.28 の場合: 管理クラスタのアップグレード中にコントロール プレーンと管理ノードがアップグレードされる
• 1.29 の場合: 管理クラスタのアップグレード中にコントロール プレーンと管理ノードがアップグレードされる

• 1.30 の場合: 管理クラスタのアップグレード中にコントロール プレーンと管理ノードがアップグレードされます。Kubeception を使用している場合、アップグレード中に次の処理が行われます。

  1. ユーザー クラスタをアップグレードします。ユーザー コントロール プレーンは管理クラスタ内に存在するため、gkectl upgrade cluster を実行するとワーカー ノードプールのみがアップグレードされます。
  2. 管理クラスタをアップグレードします。管理クラスタのアップグレードでは、管理ノードがアップグレードされ、すべてのユーザー クラスタのコントロール プレーンが同時に自動的にアップグレードされます。

• 1.31 の場合: 管理ノードは管理クラスタとともにアップグレードされます。ユーザー コントロール プレーン ノードはユーザー クラスタとともにアップグレードされます。

• 1.32 以降: Kubeception はサポートされていません。1.32 以降にアップグレードする前に、Controlplane V2 に移行する必要があります。

  Kubeception から Controlplane V2 への移行の詳細については、推奨機能へのクラスタの移行を計画するをご覧ください。

バージョン スキューとアップグレード中のバージョン スキップ

バージョン スキューとは、管理クラスタとその管理対象のユーザー クラスタのマイナー バージョンの違い、またはユーザー クラスタのコントロール プレーンとユーザー クラスタのノードプールのマイナー バージョンの違いとして許容されるものです。

バージョン スキューは、アップグレード時にマイナー バージョンをスキップすることとは異なります。

マイナー バージョンをスキップできるのは、コントロール プレーンをアップグレードした後にワーカー ノードプールをアップグレードする場合のみです。これは、バージョン 1.31 と 1.28 より前のバージョンを実行している高度なクラスタを除き、高度なクラスタと高度なクラスタ以外に適用されます。たとえば、ワーカー ノードプールがバージョン 1.29 の場合、ユーザー クラスタのコントロール プレーンを 1.30 に更新してから 1.31 に更新します。コントロール プレーンが 1.31 になったら、ワーカー ノードプールを 1.29 から 1.31 に直接アップグレードします。1.30 にアップグレードする必要はありません。詳細については、ノードプールのアップグレードでバージョンをスキップするをご覧ください。

次のマイナー リリースよりも上位のマイナー リリースにアップグレードするには、まず次のマイナー リリースにアップグレードしてから、上位のマイナー リリースにアップグレードします。管理クラスタとユーザー クラスタのコントロール プレーンをアップグレードするときに、マイナー バージョンをスキップすることはできません。たとえば、バージョン 1.34.x からバージョン 1.36.x には、直接アップグレードすることはできません。まず、1.34.x から 1.35.x にアップグレードし、続いて 1.36.x にアップグレードする必要があります。

ユーザー クラスタのコントロール プレーンは、クラスタ内のワーカー ノードプールよりも最大 2 つ高いマイナー バージョンにできます。たとえば、ユーザー クラスタのコントロール プレーンが 1.36 の場合、クラスタ内のワーカー ノードプールは 1.34、1.35、1.36 のいずれかになります。

許可されるバージョン スキュー

管理クラスタは、2 つ前までのマイナー バージョンのユーザー クラスタを管理できます。たとえば、管理クラスタが 1.31 の場合、その管理クラスタが管理するユーザー クラスタは 1.29、1.30、1.31 のいずれかになります。

バージョン 1.31 より前では、次のバージョン スキュー ルールが適用されます。

• バージョン 1.28 ～ 1.30 では、ユーザー クラスタは管理クラスタよりも最大で 2 つ後のマイナー バージョンにできます。たとえば、管理クラスタが 1.15 の場合、その管理クラスタが管理するユーザー クラスタは 1.15、1.16、1.28 のいずれかになります。管理クラスタが 1.16 以降にアップグレードされるまで、1.28 のユーザー クラスタを 1.29 にアップグレードすることはできません。バージョン 1.31 では、アップグレード順序が変更され、最初に管理クラスタをアップグレードする必要があります。そのため、1.29 または 1.30 の管理クラスタは、1.31 または 1.32 のユーザー クラスタを管理できません。管理クラスタを 1.31 にアップグレードする前に、すべてのユーザー クラスタと管理クラスタを 1.30 にアップグレードする必要があります。
• バージョン 1.16 以前では、ユーザー クラスタは管理クラスタより 1 つ後のマイナー バージョンにできます。たとえば、管理クラスタが 1.15 の場合、その管理クラスタが管理するユーザー クラスタは 1.15 または 1.16 のいずれかになります。

ユーザー クラスタを一度にすべてアップグレードする必要がありますか？

ユーザー クラスタをアップグレードするときに、次のいずれかを選択できます。

• コントロール プレーンとクラスタ内のすべてのノードプールを同時にアップグレードして、ユーザー クラスタ全体をアップグレードします。
• ユーザー クラスタのコントロール プレーンをアップグレードし、ノードプールを現在のバージョンのままにします。
• ユーザー クラスタのコントロール プレーンをアップグレードし、ノードプールを選択的にアップグレードします。

どのアプローチを採用するかは、次のような複数の要因によって異なります。

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

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

ロードバランサ ノードプール（enableLoadBalancer: true を含むノードプール）は、すべてのバージョンでクラスタと同じバージョンである必要があります。

gkectl のバージョン ルール

アップグレードに使用できる gkectl のバージョンは、ターゲット クラスタ バージョン（アップグレード先のクラスタのバージョン）によって異なります。通常、クラスタのターゲット バージョンと同じバージョンの gkectl を使用します。アップグレード中は、次のルールが適用されます。

• gkectl のバージョンは、ターゲット マイナー クラスタ バージョンと同じかそれ以降にする必要があります。たとえば、1.29 クラスタを 1.30 にアップグレードする場合は、gkectl 1.30 以降を使用する必要があります。パッチ バージョンは関係ありません。

• gkectl のバージョンは、現在のクラスタ バージョンより 2 つ前のマイナー バージョンまで使用できます。たとえば、1.28 クラスタを 1.29 にアップグレードするには、gkectl バージョン 1.29 または 1.30 を使用します。バージョン 1.31 はクラスタ バージョンより 3 つ後のマイナー バージョンであるため、使用できません。

高度なクラスタ以外のクラスタから高度なクラスタに変換する場合は、gkectl バイナリ バージョンがターゲット リリース バージョンと完全に一致している必要があります。この厳格なバージョン要件は、高度なクラスタへのアップグレード中にのみ適用されます。他のすべての高度なクラスタのアップグレードには、標準のバージョン スキュー ルールが適用されます。

パッチ バージョンのアップグレード ルール

クラスタに最新のセキュリティ修正が適用されるように、可能な限り最新のパッチ バージョンにアップグレードしてください。パッチ バージョンは、バージョン スキューとアップグレード ルールには影響しません。マイナー バージョンは、より上位のパッチ バージョンにアップグレードできます。たとえば、1.35.0 から 1.35.1 にアップグレードしたり、1.35.1 から 1.35.3 にアップグレードしたりできます。

次のステップ

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

• 高度なクラスタを有効にしてクラスタを作成する。

  • 管理クラスタを作成する
  • ユーザー クラスタを作成する
  • クラスタの更新または高度なクラスタへのアップグレードを行う