クラスタを更新または高度なクラスタにアップグレードする

このドキュメントでは、クラスタをバージョン 1.32 から高度なクラスタに更新またはアップグレードする方法について説明します。

重要: 1.33 では、高度なクラスタ以外のクラスタは自動的に高度なクラスタにアップグレードされます。

前提条件

• gkectl のバージョンは、ターゲット クラスタのバージョンと同じである必要があります。

  • 必要に応じて、gkectl をダウンロードするを参照して、サポートされているバージョンの gkectl を入手してください。

• 高度なクラスタに更新またはアップグレードする前に、必ずクラスタを診断してください。

  • 管理クラスタとユーザー クラスタで gkectl diagnose cluster を実行して、クラスタが正常であることを確認します。
  • コマンドでエラーや警告が報告された場合は、高度なクラスタへの更新またはアップグレードを開始する前に解決してください。

• クラスタが推奨機能のみを使用していることを確認します。

• 更新またはアップグレードを開始する前に、クラスタで高度なクラスタでサポートされていない機能が使用されていないことを確認します。サポートされていない機能が有効になっている場合は、まず update を使用して無効にします。

  • 高度なクラスタでは高可用性（HA）ユーザー クラスタが必要ですが、このガイドに沿って HA 以外のユーザー クラスタを HA の高度なクラスタに更新またはアップグレードすることが可能です。

• ユーザー クラスタを更新またはアップグレードする前に、管理クラスタを高度なクラスタに更新またはアップグレードしておく必要があります。

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

管理クラスタを高度なクラスタに更新またはアップグレードする

注意: 管理クラスタの更新またはアップグレードが失敗した場合は、ワークステーションから外部ブートストラップ クラスタを削除しないようにしてください。ブートストラップ クラスタには、更新またはアップグレードを再開するために必要なすべての状態が含まれています。失敗後に gkectl update admin または gkectl upgrade admin を再実行する必要がある場合は、--reuse-bootstrap-cluster（または -r）フラグを追加する必要があります。このフラグを使用しないと、重要なデータが失われるという深刻な問題が発生する可能性があります。

更新

重要: クラスタのバージョンが 1.32.0 以降であることを確認してください。

1. クラスタを診断して、正常であることを確認します。

   gkectl diagnose cluster \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG
   

   • コマンドでエラーまたは警告が報告された場合は、クラスタの問題を診断するを参照して、先に進む前に解決してください。

2. 高度なクラスタの準備をします。

   gkectl prepare \
       --bundle-path BUNDLE_PATH \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --advanced-cluster
   

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

   • BUNDLE_PATH: バンドル ファイルのパス。このファイルは管理ワークステーションの /var/lib/gke/bundles/ にあります。次に例を示します。

     /var/lib/gke/bundles/gke-onprem-vsphere-1.32.0-gke.1085-full.tgz
     

   • ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス

3. 管理クラスタ構成ファイルで、enableAdvancedCluster を true に設定します。

4. 管理クラスタを高度なクラスタに更新します。

   gkectl update admin \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --config ADMIN_CLUSTER_CONFIG
   

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

   • ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス
   • ADMIN_CLUSTER_CONFIG: 管理クラスタの構成ファイルのパス。

   このコマンドは、管理クラスタ内のすべてのノードを再作成します。

アップグレード

注意: クラスタで cos または cos_cgv2 がコントロール プレーンの OS イメージタイプまたはノードプールの OS イメージタイプとして使用されている場合は、アップグレードする前にクラスタのバージョンが 1.32.0 以上であることを確認してください。それ以外の場合は、クラスタのバージョンが 1.31.100 以上であることを確認してください。

1. 必要に応じて、管理ワークステーションをアップグレードします。

2. クラスタを診断して、正常であることを確認します。

   gkectl diagnose cluster \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG
   

   • コマンドでエラーまたは警告が報告された場合は、クラスタの問題を診断するを参照して、先に進む前に解決してください。

3. 高度なクラスタの準備をします。

   gkectl prepare \
       --bundle-path BUNDLE_PATH \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --advanced-cluster
   

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

   • BUNDLE_PATH: バンドル ファイルのパス。このファイルは管理ワークステーションの /var/lib/gke/bundles/ にあります。次に例を示します。

     /var/lib/gke/bundles/gke-onprem-vsphere-1.32.0-gke.1085-full.tgz
     

   • ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス

4. 管理クラスタ構成ファイルで、enableAdvancedCluster を true に設定します。

5. 管理クラスタ構成ファイルの bundlepath フィールドが、アップグレード先のバンドルのパスと一致していることを確認します。

6. 管理クラスタを高度なクラスタにアップグレードします。

   gkectl upgrade admin \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --config ADMIN_CLUSTER_CONFIG
   

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

   • ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス
   • ADMIN_CLUSTER_CONFIG: 管理クラスタの構成ファイルのパス。

   このコマンドによって、管理クラスタ内のすべてのノードが再作成されます。 Recreate デプロイ戦略をロールアウトすると、ノードが一度に 1 つずつアップグレードされます。ノードのアップグレード中、VM が削除され、新しいバージョンで再作成されます。

管理クラスタが更新または高度なクラスタに更新またはアップグレードされた後:

• 既存の非高度なユーザー クラスタは引き続き正常に機能します。

• 作成できるのは、高度な管理クラスタによって管理される高度なユーザー クラスタのみです。

すべてのユーザー クラスタを早めに高度なクラスタにアップグレードすることをおすすめします。これは、一貫性があり、機能が充実した環境を維持するためです。

ユーザー クラスタを高度なクラスタに更新またはアップグレードする

重要: 管理クラスタを高度なクラスタに更新またはアップグレード済みであることを確認してください。

更新

重要: クラスタのバージョンが 1.32.0 以降であることを確認してください。

1. クラスタを診断して、正常であることを確認します。

   gkectl diagnose cluster \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --cluster-name USER_CLUSTER_NAME
   

   • コマンドでエラーまたは警告が報告された場合は、クラスタの問題を診断するを参照して、先に進む前に解決してください。

2. ユーザー クラスタ コントロール プレーンが高可用性（HA）でない場合:

   注意: masterNode.replicas フィールドに関する既知の問題により、バージョン 1.32 またはバージョン 1.33 の非 HA ユーザー クラスタを HA の高度なクラスタに更新するには、クラスタのバージョンがそれぞれ 1.32.600 以降または 1.33.100 以降である必要があります。

   1. masterNode.replicas を 1 から 3 に変更します。

   2. ユーザー クラスタ コントロール プレーン ノードの静的 IP アドレスを network.controlPlaneIPBlock.ips セクションに追加します。

3. 高度なクラスタの準備をします。

   gkectl prepare \
       --bundle-path BUNDLE_PATH \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --advanced-cluster
   

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

   • BUNDLE_PATH: バンドル ファイルのパス。このファイルは管理ワークステーションの /var/lib/gke/bundles/ にあります。次に例を示します。

     /var/lib/gke/bundles/gke-onprem-vsphere-1.32.0-gke.1085-full.tgz
     

   • ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス

4. ユーザー クラスタの構成ファイルで、enableAdvancedCluster を true に設定します。

5. ユーザー クラスタを高度なクラスタに更新します。

   gkectl update cluster \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --config USER_CLUSTER_CONFIG
   

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

   • ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス
   • USER_CLUSTER_CONFIG: ユーザー クラスタの構成ファイルのパス

   このコマンドを実行すると、ユーザー クラスタ内のすべてのノードが再作成されます。 Recreate デプロイ戦略をロールアウトすると、ノードが一度に 1 つずつアップグレードされます。ノードの更新中に、VM が削除され、新しい構成で再作成されます。

アップグレード

注意: クラスタで cos または cos_cgv2 がコントロール プレーンの OS イメージタイプまたはノードプールの OS イメージタイプとして使用されている場合は、アップグレードする前にクラスタのバージョンが 1.32.0 以上であることを確認してください。それ以外の場合は、クラスタのバージョンが 1.31.100 以上であることを確認してください。

1. クラスタを診断して、正常であることを確認します。

   gkectl diagnose cluster \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --cluster-name USER_CLUSTER_NAME
   

   • コマンドでエラーまたは警告が報告された場合は、クラスタの問題を診断するを参照して、先に進む前に解決してください。

2. ユーザー クラスタ コントロール プレーンが高可用性（HA）でない場合:

   1. masterNode.replicas を 1 から 3 に変更します。

   2. ユーザー クラスタ コントロール プレーン ノードの静的 IP アドレスを network.controlPlaneIPBlock.ips セクションに追加します。

3. 高度なクラスタの準備をします。

   gkectl prepare \
       --bundle-path BUNDLE_PATH \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --advanced-cluster
   

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

   • BUNDLE_PATH: バンドル ファイルのパス。このファイルは管理ワークステーションの /var/lib/gke/bundles/ にあります。次に例を示します。

     /var/lib/gke/bundles/gke-onprem-vsphere-1.32.0-gke.1085-full.tgz
     

   • ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス

4. ユーザー クラスタの構成ファイルで、enableAdvancedCluster を true に設定します。

5. ユーザー クラスタの構成ファイルの gkeOnPremVersion フィールドが、アップグレードのターゲット バージョンと一致することを確認します。

6. ユーザー クラスタを高度なクラスタにアップグレードします。

   gkectl upgrade cluster \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --config USER_CLUSTER_CONFIG
   

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

   • ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス
   • USER_CLUSTER_CONFIG: ユーザー クラスタの構成ファイルのパス

   このコマンドを実行すると、ユーザー クラスタ内のすべてのノードが再作成されます。

高度なクラスタにバンドルされている cert-manager

cert-manager は、高度なクラスタのシステム管理コンポーネントです。

高度なクラスタを使用せずに cert-manager を使用する場合は、高度なクラスタにアップグレードする前に次のことを確認してください。

• cert-manager にカスタム構成や機能フラグはありません。
• cert-manager のバージョンが、バンドルされているバージョンと同じか、1 つ前のバージョンである。

Apigee ハイブリッドの互換性

バンドルされた cert-manager は、Apigee ハイブリッド ワークロードと完全に互換性があります。高度なクラスタにアップグレードすると、既存の cert-manager インストールが置き換えられるという警告がインストーラから表示されることがあります。これは想定された動作であり、システムによって自動的に処理されます。

Apigee ワークロードをスムーズに移行するには:

• アップグレード前に既存の cert-manager を手動でアンインストールしないでください。
• カスタマイズを元に戻す: GitOps を使用して cert-manager を管理している場合や、カスタム構成を cert-manager デプロイに適用している場合は、構成のずれやアップグレードの一時停止を防ぐために、アップグレード前にこれらのカスタマイズを元に戻すか、同期を一時停止する必要があります。

機能と制限

バンドルされた cert-manager では、次の操作を行うことができます。

• Issuer リソースと ClusterIssuer リソースを作成して編集します。
• 発行者と標準発行者タイプを参照する証明書リソースを作成して編集します。
• cert-manager が使用する標準の Kubernetes リソースを作成して編集します。
• API キーを含む Kubernetes Secret を作成し、発行者で参照します。
• 特定の HTTP-01 または DNS-01 ソルバーを使用するように発行者を構成します。

バンドルされている cert-manager では、次のものをカスタマイズできません。

• deployment または helm の値を設定します。
• cert-manager バイナリにコマンドライン引数またはフラグを追加します。
• cert-manager Pod のリソース上限またはノードセレクタを変更します。
• cert-manager ソフトウェアのインストール ロジックを変更します。
• 試験運用版機能をオンにします。
• cert-manager コントロール プレーン Pod を特定のインフラストラクチャ ノードで実行するように強制します。

バンドルされている cert-manager を使用できない特定の制約がある場合は、Google Cloud サポートにお問い合わせください。高度な構成オプションについてサポートいたします。

バンドルされたバージョン

次の表に、VMware 用 Google Distributed Cloud（ソフトウェアのみ）の各バージョンにバンドルされている cert-manager のバージョンを示します。

VMware 用 Google Distributed Cloud（ソフトウェアのみ）の概要	バンドルされた cert-manager のバージョン
1.32	1.17
1.33	1.18
1.34	1.19

高度なクラスタに移行した後の主な違い

クラスタを高度なクラスタにアップグレードまたは更新すると、標準クラスタと比較していくつかの重要な違いが生じます。高度なクラスタの主な変更点は次のとおりです。

• リソースのロケーション: クラスタとマシンのリソースは、ユーザー クラスタに配置されなくなりました。これらのリソースは、管理クラスタ内にのみ配置されます。

• NodeExternalIP: ノードに NodeExternalIP は設定されません。

• cert-manager のインストール: cert-manager は、高度なクラスタに自動的にインストールされます。クラスタに cert-manager をインストールした場合、高度なクラスタに更新またはアップグレードすると、高度なクラスタ バージョンで上書きされます。

機能の違いの概要については、機能比較表を参照してください。