ノードプールのアップグレードでマイナー バージョンをスキップする

バージョン 1.29 以降の Google Distributed Cloud では、ユーザー クラスタのコントロール プレーンを、クラスタ内のノードプールよりも最大で 2 つ後のマイナー バージョンにできます。たとえば、ユーザー クラスタのコントロール プレーンが 1.29 の場合、クラスタ内のノードプールは 1.16、1.28、1.29 のいずれかになります。また、Google Distributed Cloud では、ノードプールをアップグレードするときに 1 つのマイナー バージョンをスキップできます。前述の例では、ノードプールをバージョン 1.16 からバージョン 1.29 に直接アップグレードし、1.28 へのアップグレードをスキップできます。ノードプールをアップグレードするときにマイナー バージョンをスキップすることを、バージョン スキップ アップグレードといいます。

バージョン スキップ アップグレードがサポートされているのは、Ubuntu ノードプールと COS ノードプールのみです。Kubernetes の制約により、ユーザー クラスタのコントロール プレーンはマイナー バージョンを 1 つずつアップグレードする必要があります。しかし、コントロール プレーンのみをアップグレードすれば、ワークロードが実行されているノードプールをアップグレードするよりも時間とリスクが大幅に軽減されます。

このページでは、バージョン スキップ アップグレードのメリットの一部を紹介します。また、構成ファイルを変更して gkectl upgrade cluster を実行することでバージョン スキップ アップグレードを行う手順についても説明します。

このページは、基盤となる技術インフラストラクチャのライフサイクルを管理する IT 管理者と運用担当者を対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザー ロールとタスクをご覧ください。このページでは、以下のページに記載されているとおり、Google Distributed Cloud のアップグレードの計画と実行についてある程度理解していることを前提としています。

• アップグレードの概要

• アップグレードのベスト プラクティス

• クラスタまたはノードプールをアップグレードする

バージョン スキップ アップグレードのメリット

このセクションでは、バージョン スキップ アップグレードを行うメリットについて説明します。

クラスタをサポートされているバージョンに維持しやすくなる

Google Distributed Cloud の新しいマイナー バージョンは 4 か月ごとにリリースされます。各マイナー バージョンのサポート期間は 1 年間です。クラスタをサポート期間内に維持するには、次のとおり、約 4 か月ごとにマイナー バージョンのアップグレードを行う必要があります。

新しいマイナー バージョンの検証に長い検証期間が必要で、クラスタを新しいマイナー バージョンにアップグレードするためのメンテナンスの時間枠が短い場合、この要件が課題となります。この課題を克服するには、バージョン スキップ アップグレードを使用します。クラスタのアップグレードを 4 か月ごとではなく 8 か月ごとに行うことで、クラスタをサポート期間内に維持できます。次の表は、バージョン 1.15 のアップグレードをスキップすると、4 か月後ではなく 8 か月後にアップグレードすれば済むようになることを示しています。

ノードプールをアップグレードするときにマイナー バージョンを 1 つスキップすれば、サポート対象のバージョンを維持するために必要なアップグレードの回数を減らすことができます。また、スキップしたマイナー バージョンはコントロール プレーンで一時的に使用されるだけであるため、対応する必要はありません。

メンテナンスの時間枠が短くなる

バージョン スキップ アップグレードでは、メンテナンスの時間枠を大きく取る必要がありません。ノードプールをアップグレードするときにマイナー バージョンをスキップした場合、ノードプール内の各ノードがいったんドレインされて再作成されるため、かかる時間はノードプールを次のマイナー バージョンにアップグレードする場合と同じです。そのため、バージョン スキップ アップグレードで全体的な時間を節約し、ワークロードの中断を減らすことができます。

概要

まとめると、バージョン スキップ アップグレードのメリットは次のとおりです。

• クラスタをサポートされているバージョンにする: Google Distributed Cloud は、直近の 3 つのマイナー バージョンをサポートしています。クラスタがサポートされていないバージョンである場合、クラスタのバージョンによっては、ノードプールをアップグレードするときにマイナー バージョンをスキップすることで、アップグレードの回数を減らしつつ、クラスタをサポートされているバージョンにアップグレードできます。

• 時間を節約する: ノードプールをアップグレードするときにマイナー バージョンをスキップしても、かかる時間はノードプールを次のマイナー バージョンにアップグレードする場合と同じです。そのためバージョン スキップ アップグレードでは、ノードプールを 2 回アップグレードする場合に比べて約半分の時間で済みます。同様に、通常のアップグレードでは検証期間を 2 回設けるところ、バージョン スキップ アップグレードでは 1 回で済みます。

• 中断を減らす: アップグレードの間隔が長く、アップグレードと検証にかかる時間が短いため、ワークロードの中断が減って実行時間が長くなります。

アップグレード時のコントロール プレーンとノードプールのバージョンを制御する

ユーザー クラスタ構成ファイルの nodePools[i].gkeOnPremVersion フィールドを使用すると、特定のノードプールでトップレベルの gkeOnPremVersion フィールドとは異なるバージョンを使用できます。nodePools[i].gkeOnPremVersion フィールドの値を変更することで、gkectl upgrade cluster の実行時にノードプールがアップグレードされるタイミングを制御できます。構成ファイルで nodePools[i].gkeOnPremVersion を使用しない場合、またはこのフィールドを空の文字列に設定した場合、ノードプールは gkeOnPremVersion で指定したものと同じターゲット バージョンにアップグレードされます。

バージョン スキップ アップグレードの流れ

クラスタのコントロール プレーンとすべてのノードプールが、マイナー バージョン 1.N だとします。大まかに言うと、バージョン スキップ アップグレードを使用してクラスタを 1.N から 1.N+2 にアップグレードする方法は次のようになります。

1. コントロール プレーンのみをソース バージョン（1.N）から中間バージョン（1.N+1）にアップグレードします。ノードプールはソース バージョンのままにします。コントロール プレーンはマイナー バージョンを 1 つずつアップグレードする必要があるため、中間バージョンが必要になります。
2. コントロール プレーンとノードプールをターゲット バージョン（1.N+2）にアップグレードします。

バージョン スキップ アップグレードを実施する

このセクションでは、バージョン スキップ アップグレードを実施する手順について説明します。

始める前に

1. クラスタの現在のバージョン（ソース バージョン）がバージョン 1.16 以降であることを確認します。コントロール プレーン（gkeOnPremVersion）とすべてのノードプール（nodePools[i].gkeOnPremVersion）のバージョンを確認してください。

2. バージョン 1.29 以降では、サーバーサイドのプリフライト チェックがデフォルトで有効になっています。ファイアウォール ルールを確認し、必要に応じて変更してください。

3. バージョン 1.28 以降にアップグレードするには、kubernetesmetadata.googleapis.com を有効にして、logging-monitoring サービス アカウントに kubernetesmetadata.publisher IAM ロールを付与する必要があります。詳細については、Google API と IAM の要件をご覧ください。

アップグレードを実行する

1. 以下のプレースホルダ変数で、ソース バージョン（1.N）、中間バージョン（1.N+1）、ターゲット バージョン（1.N+2）を定義します。バージョンはすべて、1.16.11-gke.25 など、x.y.z-gke.N 形式の完全なバージョン番号にする必要があります。

   バージョン
   現在のクラスタ バージョンを取得します。これがソース バージョン（1.N）です。	SOURCE_VERSION
   中間バージョン（1.N+1）を選択します。	INTERMEDIATE_VERSION
   ターゲット バージョン（1.N+2）を選択します。ターゲット マイナー バージョンから推奨されるパッチを選択します。	TARGET_VERSION

2. 管理ワークステーションを中間バージョン INTERMEDIATE_VERSION にアップグレードします。

3. 対応するバンドルをインストールします。

   gkectl prepare \
       --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG
   

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

4. 管理ワークステーションをターゲット バージョン TARGET_VERSION にアップグレードします。

5. 対応するバンドルをインストールします。

   gkectl prepare \
       --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG
   

6. 次のように、コントロール プレーンのみ中間バージョンにアップグレードします。

   1. ユーザー クラスタの構成ファイルを次のように変更します。

      • gkeOnPremVersion フィールドを中間バージョン INTERMEDIATE_VERSION に設定します。

      • nodePools[i].gkeOnPremVersion のすべてのノードプール バージョンをソース バージョン SOURCE_VERSION に設定します。

      構成ファイルの更新が終わると、次のようになります。

      gkeOnPremVersion: INTERMEDIATE_VERSION
      ...
      nodePools:
      - name: pool-1
        gkeOnPremVersion: SOURCE_VERSION
        ...
      - name: pool-2
        gkeOnPremVersion: SOURCE_VERSION
        ...
      

   2. コントロール プレーンをアップグレードします。

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

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

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

7. 次のように、コントロール プレーンとノードプールをターゲット バージョンにアップグレードします。

   1. ユーザー クラスタの構成ファイルを次のように変更します。

      • gkeOnPremVersion フィールドをターゲット バージョン TARGET_VERSION に設定します。

      • すべての nodePools[i].gkeOnPremVersion を空の文字列に設定します。

      構成ファイルの更新が終わると、次のようになります。

      gkeOnPremVersion: TARGET_VERSION
      ...
      nodePools:
      - name: pool-1
        gkeOnPremVersion: ""
        ...
      - name: pool-2
        gkeOnPremVersion: ""
        ...
      

   2. コントロール プレーンとノードプールをアップグレードします。

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

次のステップ

• ノードプールの作成と管理
• ノードプールの更新ポリシーを構成する