クラスタをアップグレードする

新しいバージョンの bmctl をインストールすると、以前のバージョンで作成した既存のクラスタをアップグレードできます。Google Distributed Cloud の最新バージョンにクラスタをアップグレードすると、クラスタに追加機能と修正が適用されます。また、引き続きクラスタのサポートを保証します。管理クラスタ、ハイブリッド クラスタ、スタンドアロン クラスタ、ユーザー クラスタは、「bmctl upgrade cluster」コマンドを使用するか、kubectl を使用してアップグレードできます。

アップグレード プロセスとバージョニング ルールの詳細については、クラスタ アップグレードのライフサイクルとステージをご覧ください。

このページは、基盤となる技術インフラストラクチャのライフサイクルを管理する管理者、アーキテクト、オペレーターを対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。

アップグレードを計画する

このセクションでは、クラスタをアップグレードする前に考慮すべき情報とリンクを提供します。クラスタとノードプールのバージョニング ルールなど、アップグレードの詳細については、クラスタ アップグレードのライフサイクルとステージをご覧ください。

ベスト プラクティス

クラスタのアップグレードの準備にについては、Google Distributed Cloud クラスタのアップグレードに関するベスト プラクティスをご覧ください。

プリフライト チェックをアップグレードする

プリフライト チェックは、クラスタのアップグレードの一環として実行され、クラスタのステータスとノードの健全性を検証します。プリフライト チェックに失敗した場合、クラスタのアップグレードは続行されません。プリフライト チェックの詳細については、プリフライト チェックをご覧ください。

アップグレードを実行する前に、プリフライト チェックを実行することで、クラスタのアップグレードの準備ができているかどうかを確認できます。詳しくは、アップグレードのプリフライト チェックをご覧ください。

既知の問題

クラスタのアップグレードに関連する潜在的な問題については、Google Distributed Cloud for bare metal の既知の問題を参照し、[アップグレードと更新] 問題カテゴリを選択してください。

アップグレード オプションの構成

クラスタのアップグレードを始める前に、次のアップグレード オプションを構成してアップグレード プロセスの動作を制御できます。

これらのオプションにより、重要なアプリケーションやサービスの停止のリスクを低減し、全体的なアップグレード時間を大幅に短縮できます。これらのオプションは、多数のノードを持つ大規模なクラスタと重要なワークロードを実行しているノードプールに特に役立ちます。これらのオプションの機能と使用方法の詳細については、以降のセクションをご覧ください。

選択的なノードプールのアップグレード

デフォルトでは、クラスタのアップグレード オペレーションによって、クラスタ内のすべてのノードとノードプールがアップグレードされます。各ノードがドレインされ、関連するすべての Pod が再起動および再スケジュールされるため、クラスタのアップグレードは中断を伴う可能性があり、時間がかかることがあります。このセクションでは、クラスタのアップグレードのためにワーカー ノードプールの一部を追加または除外して、ワークロードの中断を最小限に抑える方法について説明します。この機能は、ユーザー クラスタ、ハイブリッド クラスタ、スタンドアロン クラスタにのみ適用されます。これは、管理クラスタにはワーカー ノードプールを持てないためです。

選択的なノードプールのアップグレードは、次の状況で使用できます。

  • ワークロードを中断することなくセキュリティ修正を適用するため: コントロール プレーン ノード（およびロードバランサ ノード）のみをアップグレードして、ワーカー ノードプールを中断することなく Kubernetes の脆弱性の修正を適用できます。

  • すべてのワーカーノードをアップグレードする前に、アップグレードされたワーカーノードのサブセットが適切に動作することを確認するため: ワーカー ノードプールを選択的にアップグレードして、別のノードプールをアップグレードする前に、アップグレードされたノードプールでワークロードが正しく実行されていることを確認できます。

  • メンテナンスの時間枠を短縮するため: 大規模なクラスタのアップグレードには時間がかかる場合があり、アップグレードの完了を正確に予測することは困難です。クラスタのアップグレード時間は、アップグレードするノードの数に比例します。ノードプールを除外して、アップグレードされるノードの数を減らすと、アップグレード時間を短縮できます。アップグレードは複数回行いますが、メンテナンスの時間枠がより小規模で予測しやすいほどスケジューリングに役立ちます。

2 マイナー バージョンのノードプール バージョン スキュー

バージョン 1.28 以降のクラスタでは、ワーカー ノードプールのバージョンは、クラスタ（コントロール プレーン）のバージョンより最大 2 低いマイナー バージョンを使用できます。n-2 バージョン スキューのサポートにより、クラスタより下位の 2 つのマイナー バージョンからクラスターと同じマイナーバージョンにワーカーノードプールをアップグレードするときに、マイナー リリース バージョンをスキップすることもできます。

ワーカー ノードプールに対する n-2 のバージョン スキューのサポートにより、フリートのアップグレードをより柔軟に計画できます。

たとえば、バージョン 1.30 クラスタを使用している場合、ワーカー ノードプールをバージョン 1.30、1.29、または 1.28 バージョンで作成できます。

クラスタをアップグレードする前に、すべてのワーカー ノードプールを現在のクラスタ バージョンとターゲット クラスタ バージョンの両方と互換性のあるバージョンにする必要があります。

たとえば、クラスタがバージョン 1.29 で、ワーカー ノードプールがバージョン 1.29、バージョン 1.28、バージョン 1.16 の場合、クラスタをバージョン 1.30 にアップグレードする前に、バージョン 1.16 ノードプールをバージョン 1.28 または 1.29 にアップグレードする必要があります。

特定のクラスタ バージョンに対してサポートされているワーカー ノードプールのバージョンの詳細（バージョン 1.29 以前が対象）については、ノードプールのバージョニング ルールをご覧ください。

1.30

リリース 1.30 では、すべてのクラスタタイプに対してワーカー ノードプールの n-2 バージョン スキューのサポートが一般提供されています。バージョン 1.30 のクラスタでは、この機能はデフォルトで有効になっています。

ノードプールのバージョンがクラスタ バージョンと同じかそれより低い場合、1.28 と 1.29 マイナー バージョンの任意のパッチ バージョンのノードプールは、1.30 の任意のパッチ バージョンにアップグレードできます。

1.29

リリース 1.29 では、すべてのクラスタタイプに対してワーカー ノードプールの n-2 バージョン スキューのサポートが一般提供されています。バージョン 1.29 のクラスタでは、この機能はデフォルトで有効になっています。

この機能はパブリック プレビューから一般提供に移行中のため、次の状況では、ハイブリッド クラスタに対して引き続きプレビュー アノテーションが必要になります。バージョン 1.16.y ワーカー ノードプールがあるバージョン 1.28.x のハイブリッド クラスタがある場合は、バージョン 1.29.z にアップグレードする前にクラスタに preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable アノテーションを追加する必要があります。

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
    preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
spec:
  type: hybrid
  profile: default
  anthosBareMetalVersion: 1.28.400-gke.77
  ...

1.28

ワーカー ノードプールに対する n-2 バージョン スキューのサポートは、リリース 1.28 のプレビュー版で利用できます。このプレビュー機能を有効にするには、クラスタ構成ファイルに preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable アノテーションを追加します。

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
    preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
spec:
...

このプレビュー機能を有効にしない場合、ワーカー ノードプールとクラスタの間の最大バージョン スキューは、1 マイナー バージョンです。

ワーカー ノードプールを選択的にアップグレードするためのバージョニング ルールの詳細については、ライフサイクルにおけるノードプールのバージョニング ルールとクラスタ アップグレードのステージをご覧ください。

クラスタ コントロール プレーンと選択したノードプールのアップグレード

最初のクラスタ アップグレードでワーカー ノードプールを選択してアップグレードするには:

  1. クラスタのアップグレードに含めるワーカー ノードプールの場合は、NodePool 仕様に次のいずれかの変更を加えます。

    • NodePool 仕様の anthosBareMetalVersion をクラスター ターゲット アップグレード バージョンに設定します。
    • NodePool 仕様の anthosBareMetalVersion フィールドを省略するか、空の文字列に設定します。デフォルトでは、すべてのワーカー ノードプールがクラスタ アップグレードの対象となります。

  2. アップグレードから除外するワーカー ノードプールについて、anthosBareMetalVersion をクラスタの現在の（アップグレード前の）バージョンに設定します。

  3. クラスタのアップグレードを開始するの説明に沿って、アップグレードを続行します。

    クラスタのアップグレード オペレーションでは、以下のノードがアップグレードされます。

    • クラスタのコントロール プレーン ノード
    • クラスタでロードバランサ ノードプールを使用している場合（spec.loadBalancer.nodePoolSpec）は、ロードバランサ ノードプール。デフォルトでは、ロードバランサ ノードは通常のワークロードを実行できます。ロードバランサ ノードプールは、最初のクラスタ アップグレードに常に含まれるため、選択的にアップグレードすることはできません。
    • アップグレードから除外していないワーカー ノードプール。

たとえば、クラスタのバージョンが 1.29.0 で、2 つのワーカー ノードプール（wpool01 と wpool02）があるとします。また、コントロール プレーンと wpool01 は 1.30.300-gke.84 にアップグレードしますが、wpool02 はバージョン 1.29.0 のままにするとします。

次のクラスタ構成ファイルの例では、この部分的なアップグレードをサポートするためにクラスタ構成を変更する方法を示します。

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.30.300-gke.84
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.30.300-gke.84
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.8

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool02
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.29.0
  nodes:
  - address:  10.200.1.1
  - address:  10.200.1.2
  - address:  10.200.1.3
  ...
  - address:  10.200.1.12

ノードプールを現在のクラスタ バージョンにアップグレードする

クラスタのアップグレードからノードプールを除外した場合は、クラスタ アップグレードを実行することで、ノードプールをターゲット クラスタのバージョンに引き上げることができます。クラスタ アップグレードから除外されたワーカー ノードプールは、NodePool 仕様の anthosBareMetalVersion フィールドが以前の（アップグレード前の）クラスタ バージョンに設定されています。

ワーカー ノードプールを現在の（アップグレード後の）クラスタ バージョンにアップグレードするには:

  1. クラスタ構成ファイルの NodePool の仕様を、現在のクラスタ バージョンにアップグレードするワーカー ノードプール用に編集します。anthosBareMetalVersion を現在の（アップグレード後の）クラスタ バージョンに設定します。

    アップグレードの対象として複数のワーカー ノードプールが選択されている場合、クラスタ仕様の spec.nodePoolUpgradeStrategy.concurrentNodePools の値によって、並列でアップグレードされるノードプールの数が決まります（存在する場合）。ワーカー ノードプールを同時にアップグレードしない場合は、アップグレードするノードプールを一つずつ選択します。

  2. クラスタのアップグレードを開始するの説明に沿って、アップグレードを続行します。

    クラスタ アップグレード オペレーションは、以前に anthosBareMetalVersion を現在のアップグレードされたクラスタ バージョンに設定して除外したワーカー ノードプールのみをアップグレードします。

たとえば、クラスタをバージョン 1.30.300-gke.84 にアップグレードし、ノードプール wpool02 はアップグレード前の古いクラスタ バージョン 1.29.0 のままだとします。ワークロードがアップグレードしたノードプール（wpool01）で正常に動作しているので、wpool02 も現在のクラスタ バージョンにアップグレードします。wpool02 をアップグレードするには、anthosBareMetalVersion フィールドを削除するか、空の文字列に設定します。

次のクラスタ構成ファイルの例では、この部分的なアップグレードをサポートするためにクラスタ構成を変更する方法を示します。

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.30.300-gke.84
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.30.300-gke.84
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.8

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool02
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: ""
  nodes:
  - address:  10.200.1.1
  - address:  10.200.1.2
  - address:  10.200.1.3
  ...
  - address:  10.200.1.12

ノードプールのアップグレードをロールバックする

kubelet やプラグインとの互換性など、ワークロードのパフォーマンスに影響する依存関係は数多く存在します。ワーカー ノードプールのアップグレード後に問題が発生した場合は、ノードプールを以前のバージョンにロールバックできます。

この機能は、サポートされているすべてのクラスタ バージョンで同じリリース フェーズにあるわけではありません。

1.30

バージョン 1.30 クラスタ（バージョン 1.30 のコントロール プレーン ノードのあるクラスタ）では、ノードプールのロールバック機能が一般提供され、デフォルトで有効になっています。

1.29

ノードプールのロールバック機能は、バージョン 1.29 クラスタ（バージョン 1.29 のコントロール プレーン ノードのあるクラスタ）でプレビュー版として利用できます。この機能はプレビュー版のため、機能を有効にするには、Cluster リソースに次のアノテーションを追加する必要があります。

preview.baremetal.cluster.gke.io/worker-node-pool-upgrade-rollback: enable

1.28

ノードプールのロールバック機能は、マイナー バージョン 1.28 以前のクラスタでは使用できません。

ノードプールのアップグレードをロールバックするには、次の操作を行います。

bmctl

bmctl を使用してノードプールのアップグレードをロールバックする場合は、クラスタ構成ファイルを編集し、bmctl update コマンドで変更を適用します。

  1. クラスタ構成ファイルで、以前のバージョンにロールバックするワーカー ノードプールの NodePool 仕様を編集します。anthosBareMetalVersion を以前の（アップグレード前の）クラスタ バージョンに設定します。

    ...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.29.800-gke.111
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...

    ロールバックの対象として複数のワーカー ノードプールが選択されている場合、クラスタ仕様の spec.nodePoolUpgradeStrategy.concurrentNodePools の値によって、並行してロールバックされるノードプールの数が決まります。ワーカー ノードプールを同時にロールバックしない場合は、ロールバックするノードプールを 1 つずつ選択するか、nodePoolUpgradeStrategy 設定を更新します。同様に、NodePool 仕様の spec.upgradeStrategy.parallelUpgrade.concurrentNodes の値によって、並行してロールバックされるノードの数が決まります。

  2. bmctl update を使用して、NodePool 仕様の変更を適用します。

    bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG

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

    • CLUSTER_NAME: 更新するクラスタの名前。

    • ADMIN_KUBECONFIG: 管理側のクラスタ（管理、ハイブリッド、スタンドアロン）の kubeconfig ファイルのパス。

    ロールバックが自動的に開始します。bmctl update cluster コマンドはすぐに終了しますが、ロールバックは続行されます。ロールバックの進行中は、クラスタに対して他のオペレーションを実行しないでください。

  3. ロールバックの実行時に、Google Distributed Cloud は各ノードに対して次の処理を行います。

    • ノードをメンテナンス モードに切り替えます。
    • ノードでリセットジョブを実行し、クリーンな状態に戻します。
    • ノードでマシンのプリフライト チェックを実行します。
    • ノードで machine-init ジョブを実行し、ターゲットのロールバック（アップグレード前の）バージョンで再インストールします。
    • ノードをメンテナンス モードから切り替えます。

    ロールバックに成功すると、NodePool リソースの nodePool.status.anthosBareMetalVersion の値がターゲット ロールバック バージョンに設定されます。

kubectl

kubectl を使用して NodePool リソースを直接編集することで、ノードプールのアップグレードをロールバックできます。

  1. ワーカー ノードプールをロールバックするには、NodePool リソースを開いて以下のように編集します。

    kubectl edit nodepool NODE_POOL_NAME \
    --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

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

    • NODE_POOL_NAME: ロールバックするノードプールの名前。

    • CLUSTER_NAMESPACE: ノードプールがデプロイされる名前空間の名前。これはクラスタの Namespace です。

    • ADMIN_KUBECONFIG: 管理側のクラスタ（管理、ハイブリッド、スタンドアロン）の kubeconfig ファイルのパス。

  2. spec.anthosBareMetalVersion の値を以前の（アップグレード前の）バージョンに変更します。

    ...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.29.800-gke.111
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...

  3. エディタで NodePool リソースを保存して閉じます。

    ロールバックが自動的に開始します。ロールバックの進行中は、クラスタに対して他のオペレーションを実行しないでください。

  4. ロールバックの実行時に、Google Distributed Cloud は各ノードに対して次の処理を行います。

    • ノードをメンテナンス モードに切り替えます。
    • ノードでリセットジョブを実行し、クリーンな状態に戻します。
    • ノードでマシンのプリフライト チェックを実行します。
    • ノードで machine-init ジョブを実行し、ターゲットのロールバック（アップグレード前の）バージョンで再インストールします。
    • ノードをメンテナンス モードから切り替えます。

    ロールバックが成功すると、NodePool リソースの nodePool.status.anthosBareMetalVersion の値がターゲット ロールバック バージョンに設定されます。

並列アップグレード

一般的なデフォルトのクラスタ アップグレードでは、各クラスタノードが順番に（一つずつ）アップグレードされます。このセクションでは、クラスタをアップグレードするときに複数のノードを並行してアップグレードするように、クラスタとワーカー ノードプールを構成する方法について説明します。ノードを並行してアップグレードすると、特に数百のノードがあるクラスタの場合に、クラスタのアップグレードがかなり速くなります。

クラスタのアップグレードを高速化するために使用できる並列アップグレート方法には、次の 2 つがあります。

  • ノードの同時アップグレード: 複数のノードが並行してアップグレードされるようにワーカー ノードプールを構成できます。ノードの並列アップグレードは NodePool 仕様（spec.upgradeStrategy.parallelUpgrade）で構成します。ワーカー ノードプール内のノードだけが並列でアップグレードされます。コントロール プレーンやロードバランサのノードプール内のノードは、一つずつアップグレードできます。詳細については、ノードのアップグレード方法をご覧ください。

  • ノードプールの同時アップグレード: 複数のノードプールが並行してアップグレードされるようにクラスタを構成できます。ワーカー ノードプールのみ並列でアップグレードできます。コントロール プレーンとロードバランサのノードプールは、一つずつアップグレードできます。

ノードのアップグレード方法

複数のノードが同時にアップグレードするようにワーカー ノードプールを構成できます（concurrentNodes）。また、アップグレード プロセス全体で、ワークロードを実行できるノードの数の最小しきい値を設定することもできます（minimumAvailableNodes）。この構成は NodePool 仕様で行います。これらのフィールドの詳細については、クラスタ構成フィールド リファレンスをご覧ください。

ノードのアップグレード方法は、ワーカー ノードプールにのみ適用されます。コントロール プレーンやロードバランサのノードプールにノードのアップグレード方法は指定できません。クラスタのアップグレード中は、コントロール プレーンとロードバランサのノードプール内のノードが一つずつアップグレードされます。コントロール プレーン ノードプールとロードバランサ ノードプールは、Cluster 仕様（controlPlane.nodePoolSpec.nodes と loadBalancer.nodePoolSpec.nodes）で指定します。

ノードの並列アップグレードを構成する場合は、次の制限に注意してください。

  • concurrentNodes の値は、ノードプール内のノード数の 50% か固定数 15 のいずれか小さいほうになります。たとえば、ノードプールに 20 個のノードがある場合、10 より大きい値は指定できません。ノードプールに 100 個のノードがある場合は、15 が指定できる最大値です。

  • minimumAvailableNodes と一緒に concurrentNodes を使用する場合、その合計値はノードプール内のノードの合計数を超えることはできません。たとえば、ノードプールに 20 個のノードがあり、minimumAvailableNodes が 18 に設定されている場合、concurrentNodes は 2 以下にする必要があります。同様に、concurrentNodes が 10 に設定されている場合、minimumAvailableNodes は 10 以下にする必要があります。

次の例では、10 個ノードがあるワーカー ノードプール np1 を示します。アップグレードでは、ノードは一度に 5 つアップグレードされます。アップグレードを続行させるためには、少なくとも 4 つのノードが使用可能である必要があります。

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-cluster1
spec:
  clusterName: cluster1
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  - address:  10.200.0.4
  - address:  10.200.0.5
  - address:  10.200.0.6
  - address:  10.200.0.7
  - address:  10.200.0.8
  - address:  10.200.0.9
  - address:  10.200.0.10 
  upgradeStrategy:
    parallelUpgrade:
      concurrentNodes: 5
      minimumAvailableNodes: 4

ノードプールのアップグレード方法

複数のワーカー ノードプールが並行してアップグレードするようにクラスタを構成できます。クラスタ仕様の nodePoolUpgradeStrategy.concurrentNodePools ブール値フィールドには、クラスタのすべてのワーカー ノードプールを同時にアップグレードするかどうかを指定します。デフォルト（1）では、ノードプールが順番に（一つずつ）アップグレードされます。concurrentNodePools を 0 に設定すると、クラスタ内のすべてのワーカー ノードプールが並行してアップグレードされます。

コントロール プレーンとロード バランシングのノードプールは、この設定の影響を受けません。これらのノードプールは常に一つずつ順番にアップグレードされます。コントロール プレーン ノードプールとロードバランサ ノードプールは、Cluster 仕様（controlPlane.nodePoolSpec.nodes と loadBalancer.nodePoolSpec.nodes）で指定します。

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...

並列アップグレードの実行方法

このセクションでは、並列アップグレード用にクラスタとワーカー ノードプールを構成する方法について説明します。

ワーカー ノードプールとワーカー ノードプール内のノードの並列アップグレードを実行するには、次の操作を行います。

  1. NodePool 仕様に upgradeStrategy セクションを追加します。

    このマニフェストは個別に適用することも、クラスタの更新を実行するときにクラスタ構成ファイルの一部として適用することもできます。

    次に例を示します。

    ---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-ci-bf8b9aa43c16c47
spec:
  clusterName: ci-bf8b9aa43c16c47
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.30
  upgradeStrategy:
    parallelUpgrade:
      concurrentNodes: 5
      minimumAvailableNodes: 10

    この例では、フィールド concurrentNodes の値は 5 です。つまり、5 つのノードが並列にアップグレードされます。minimumAvailableNodes フィールドは 10 に設定されています。つまり、アップグレード中は、少なくとも 10 ノードをワークロードに使用できる必要があります。

  2. クラスタ構成ファイルの Cluster 仕様に nodePoolUpgradeStrategy セクションを追加します。

    ---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user001
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.30.300-gke.84
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...

    この例では、concurrentNodePools フィールドが 0 に設定されています。つまり、クラスタのアップグレード中にすべてのワーカー ノードプールが同時にアップグレードされます。ノードプール内のノードのアップグレード方法は、NodePool 仕様で定義されています。

  3. 前の管理クラスタ、スタンドアロン クラスタ、ハイブリッド クラスタ、ユーザー クラスタをアップグレードするのセクションの説明に沿ってクラスタをアップグレードします。

並列アップグレードのデフォルト値

並列アップグレードはデフォルトで無効になっています。並列アップグレードに関連するフィールドは変更可能です。いつでも、フィールドを削除するか、デフォルト値に設定することで、後続のアップグレートの前にこの機能を無効にできます。

次の表では、並列アップグレード フィールドとそのデフォルト値を示します。

フィールド デフォルト値 意味
nodePoolUpgradeStrategy.concurrentNodePools（クラスタ仕様） 1 ワーカー ノードプールを順番に（一つずつ）アップグレードします。
upgradeStrategy.parallelUpgrade.concurrentNodes（NodePool 仕様） 1 ノードを順番に（一つずつ）アップグレードします。
upgradeStrategy.parallelUpgrade.minimumAvailableNodes（NodePool 仕様） デフォルトの minimumAvailableNodes 値は concurrentNodes の値によって異なります。
  • concurrentNodes を指定しない場合、minimumAvailableNodes のサイズはデフォルトでノードプールの 2/3 です。
  • concurrentNodes を指定する場合、デフォルトでは、minimumAvailableNodes はノードプール サイズから concurrentNodes を引いた値になります。
 minimumAvailableNodes に達すると、アップグレードは停止し、使用可能なノード数が minimumAvailableNodes を超えるとアップグレードが続行されます。

クラスタのアップグレードを開始する

このセクションでは、クラスタのアップグレード手順について説明します。

bmctl

新しいバージョンの bmctl をダウンロードしてインストールすると、以前のバージョンで作成した管理クラスタ、ハイブリッド クラスタ、スタンドアロン クラスタ、ユーザー クラスタをアップグレードできます。bmctl のバージョンによっては、クラスタを同じバージョンにしかアップグレードできない場合があります。

  1. ユーザー認証情報をアプリケーションのデフォルト認証情報（ADC）として設定します。

    gcloud auth application-default login

    画面の指示に沿って、ADC 用の Google アカウントを選択します。詳細については、アプリケーションのデフォルト認証情報を設定するをご覧ください。

  2. Google Distributed Cloud のダウンロードの説明に従って、最新の bmctl をダウンロードします。

  3. クラスタ構成ファイルの anthosBareMetalVersion をアップグレード対象のバージョンに更新します。

    アップグレード対象のバージョンは、ダウンロードした bmctl ファイルのバージョンと一致している必要があります。次のクラスタ構成ファイル スニペットでは、最新バージョンに更新された anthosBareMetalVersion フィールドを示します。

    ---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  type: admin
  # Anthos cluster version.
  anthosBareMetalVersion: 1.30.300-gke.84

  4. bmctl upgrade cluster コマンドを使用してアップグレードを完了します。

    bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    以下を置き換えます。

    • CLUSTER_NAME: アップグレードするクラスタの名前。
    • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。

    クラスタ アップグレード オペレーションでは、プリフライト チェックが実行され、クラスタのステータスとノードの健全性が検証されます。プリフライト チェックに失敗した場合、クラスタのアップグレードは続行されません。トラブルシューティング情報については、クラスタのインストールやアップグレードに関する問題のトラブルシューティングをご覧ください。

    すべてのクラスタ コンポーネントが正常にアップグレードされると、クラスタのヘルスチェックが実行されます。この最後の手順で、クラスタが正常な運用状態にあることを確認します。クラスタがすべてのヘルスチェックに合格しない場合は、合格するまで実行を継続します。すべてのヘルスチェックに合格すると、アップグレードが正常に完了します。

    クラスタのアップグレードのイベントの順序について詳しくは、クラスタ アップグレードのライフサイクルとステージをご覧ください。

kubectl

kubectl を使用してクラスタをアップグレードするには、次の操作を行います。

  1. クラスタ構成ファイルを編集して、anthosBareMetalVersion をアップグレード先のターゲット バージョンに設定します。

  2. アップグレードを開始するには、次のコマンドを実行します。

    kubectl apply -f CLUSTER_CONFIG_PATH

    CLUSTER_CONFIG_PATH は、編集したクラスタ構成ファイルのパスに置き換えます。

    bmctl を使用したアップグレード プロセスと同様に、クラスタのアップグレードの一環としてプリフライト チェックが実行され、クラスタのステータスとノードの健全性が検証されます。プリフライト チェックが不合格の場合、クラスタのアップグレードは停止します。ブートストラップ クラスタが作成されないため、障害をトラブルシューティングするには、クラスタと関連ログを調べます。詳細については、クラスタのインストールやアップグレードに関する問題のトラブルシューティングをご覧ください。

kubectl でクラスタをアップグレードするために bmctl の最新バージョンは必要ありませんが、最新の bmctl をダウンロードすることをおすすめします。クラスタが正常に動作するように、ヘルスチェックやバックアップなどの他のタスクを実行するには bmctl が必要です。

アップグレードの一時停止と再開

アップグレードの一時停止と再開機能を使用すると、クラスタのアップグレードが完了する前に処理を一時的に停止できます。クラスタのアップグレードが一時停止されると、アップグレードが再開されるまで、新しいワーカーノードのアップグレードはトリガーされません。

この機能は、すべてのコントロール プレーン ノードがマイナー バージョン 1.28 以降であるクラスタ（プレビュー版）で利用できます。この機能は、すべてのコントロール プレーン ノードがマイナー バージョン 1.29 以降であるクラスタで一般提供されています。

次のような場合は、アップグレードの一時停止をおすすめします。

  • アップグレード中にクラスタ ワークロードに問題が見つかり、アップグレードを一時停止して問題を調査する必要がある

  • メンテナンスの時間枠が短いため、時間枠間のアップグレードを一時停止する

クラスタのアップグレードが一時停止している間は、次の操作がサポートされています。

アップグレードが一時停止しているときに新しいノードが追加された場合、アップグレードが再開されて完了するまで、マシンチェック ジョブは実行されません。

クラスタのアップグレードが一時停止されている間、次のクラスタ操作はサポートされません。

アクティブなクラスタ アップグレードが一時停止している間は、新しいクラスタのアップグレードを開始できません。

アップグレードの一時停止と再開を有効にする

Google Distributed Cloud 1.30

コントロール プレーン ノードがすべてマイナー バージョン 1.29 以降のクラスタでは、アップグレードの一時停止と再開機能がデフォルトで有効になっています。

Google Distributed Cloud 1.29

アップグレードの一時停止と再開機能はプレビュー版ですが、Cluster リソースのアノテーションを使用して有効にできます。

アップグレードの一時停止と再開を有効にするには、次の手順を行います。

  1. アノテーション preview.baremetal.cluster.gke.io/upgrade-pause-and-resume をクラスタ構成ファイルに追加します。

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
    preview.baremetal.cluster.gke.io/upgrade-pause-and-resume
spec:
...

  2. 変更を適用するには、クラスタを更新します。

    bmctl update CLUSTER_NAME

    nodePoolUpgradeStrategy.pause フィールドは変更可能です。いつでも追加、更新できます。

アップグレードの一時停止

クラスタ アップグレードを一時停止するには、クラスタ仕様にある nodePoolUpgradeStrategy.pause を true に設定します。

アクティブなクラスタのアップグレードを一時停止するには、次の操作を行います。

  1. nodePoolUpgradeStrategy.pause をクラスタ構成ファイルに設定し、それを true に設定します。

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  ...
spec:
  ...
  nodePoolUpgradeStrategy:
    pause: true
  ...

    bmctl を使用してアップグレードを開始した場合は、次のステップを実行するために新しいターミナル ウィンドウを開く必要があります。

  2. 変更を適用するには、クラスタを更新します。

    bmctl update CLUSTER_NAME

    アップグレード オペレーションが一時停止します。新しいノードのアップグレードはトリガーされません。

  3. bmctl を使用してアップグレードを開始し、長期的な一時停止を計画している場合は、Ctrl+C キーを押して bmctl を終了します。そうしない場合、bmctl は実行されつづけます。

    bmctl CLI は、アップグレードの一時停止ステータスの変更を検出できないため、自動的に終了しません。ただし、bmctl を終了すると、管理ワークステーションのクラスタ フォルダにある cluster-upgrade-TIMESTAMP ログファイルと Cloud Logging へのアップグレード状況のロギングが停止します。そのため、一時停止が短い場合は bmctl を実行したままにすることをおすすめします。アップグレードが一時停止している間に bmctl を長時間実行すると、最終的にはタイムアウトします。

一時停止したアップグレードの再開

一時停止したクラスタのアップグレードを再開するには、Cluster 仕様で nodePoolUpgradeStrategy.pause を false に設定するか、仕様から nodePoolUpgradeStrategy.pause を削除します。

一時停止したクラスタのアップグレードを再開するには、次の手順を行います。

  1. nodePoolUpgradeStrategy.pause をクラスタ構成ファイルに設定し、それを false に設定します。

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  ...
spec:
  ...
  nodePoolUpgradeStrategy:
    pause: false
  ...

    また、pause フィールドはデフォルトが false であるため、削除することもできます。

  2. 変更を適用するには、クラスタを更新します。

    bmctl update CLUSTER_NAME

    アップグレード オペレーションは、中断したところから再開します。

  3. アップグレードのステータスを確認するには、まず status に anthosBareMetalVersion があるリソースのリストを取得します。

    kubectl get RESOURCE --kubeconfig ADMIN_KUBECONFIG --all_namespaces

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

    • RESOURCE: 取得するリソースの名前。Cluster、NodePool、BareMetalMachine リソースは、すべて anthosBareMetalVersion ステータス情報があります。

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

    次の例では、BareMetalMachine カスタム リソースのレスポンスの形式を示します。各 BareMetalMachine はクラスタノードに対応します。

    NAMESPACE              NAME         CLUSTER        READY   INSTANCEID               MACHINE      ABM VERSION   DESIRED ABM VERSION
cluster-nuc-admin001   192.0.2.52   nuc-admin001   true    baremetal://192.0.2.52   192.0.2.52   1.28.0        1.28.0
cluster-nuc-user001    192.0.2.53   nuc-user001    true    baremetal://192.0.2.53   192.0.2.53   1.16.2        1.16.2
cluster-nuc-user001    192.0.2.54   nuc-user001    true    baremetal://192.0.2.54   192.0.2.54   1.16.2        1.16.2

  4. status.anthosBareMetalVersion（リソースの現在のバージョン）を確認するには、個々のリソースの詳細を取得します。

    kubectl describe RESOURCE RESOURCE_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --namespace CLUSTER_NAMESPACE

    次のサンプルでは、IP アドレス 192.0.2.53 のクラスタノードの BareMetalMachine の詳細を示します。

    Name:         192.0.2.53
Namespace:    cluster-nuc-user001
...
API Version:  infrastructure.baremetal.cluster.gke.io/v1
Kind:         BareMetalMachine
Metadata:
  Creation Timestamp:  2023-09-22T17:52:09Z
  ...
Spec:
  Address:                    192.0.2.53
  Anthos Bare Metal Version:  1.16.2
  ...
Status:
  Anthos Bare Metal Version:  1.16.2

    この例では、ノードは Google Distributed Cloud バージョン 1.16.2 です。