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

バージョン 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 か月ごとにマイナー バージョンのアップグレードを行う必要があります。

12 月

1 月

2 月

3 月

4 月

5 月

6 月

7 月

8 月

9 月

10 月

11 月

12 月

1 月

2 月

3 月

4 月

5 月

6 月

7 月

8 月

9 月

10 月

11 月

12 月

1 月

2 月

3 月
1.14 アップグレード
1.15 アップグレード
1.16 アップグレード
1.28 アップグレード
1.29 アップグレード

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

12 月

1 月

2 月

3 月

4 月

5 月

6 月

7 月

8 月

9 月

10 月

11 月

12 月

1 月

2 月

3 月

4 月

5 月

6 月

7 月

8 月

9 月

10 月

11 月

12 月

1 月

2 月

3 月
1.14 アップグレード
1.15
1.16 アップグレード
1.28
1.29

ノードプールをアップグレードするときに 1 つのマイナー バージョンをスキップすると、サポート対象バージョンを維持するために必要なアップグレードの数が減ります。また、スキップされたマイナー バージョンはコントロール プレーンによって一時的にのみ使用されるため、修飾する必要はありません。

メンテナンスの時間枠の短縮

バージョンをスキップしてアップグレードする場合、メンテナンスの時間枠を拡大する必要はありません。ノードプールをアップグレードするときにマイナー バージョンをスキップすると、ノードプール内の各ノードがドレインされて 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

次のステップ