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

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

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

前提条件

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

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

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

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

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

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

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

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

更新

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

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

   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 ファイルのパス

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

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

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

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

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

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

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

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

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

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

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

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

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

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

更新

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

1. ユーザー クラスタ コントロール プレーンが高可用性（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 セクションに追加します。

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 cluster \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --config USER_CLUSTER_CONFIG
   

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

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

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

アップグレード

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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