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

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

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

注: セキュリティ パッチを含むバージョンから次のマイナー リリースに Google Distributed Cloud をアップグレードする場合は、利用可能な最も高いパッチ バージョンにアップグレードして、最新のセキュリティ パッチを適用することをおすすめします。アップグレードの前にリリースノートを確認し、セキュリティ修正や既知の問題など、変更内容を把握してください。クラスタの下位バージョンへのダウングレードはサポートされていません。

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

このセクションでは、クラスタをアップグレードする前に考慮すべき情報とリンクを提供します。

ベスト プラクティス

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

アップグレードのプリフライト チェック

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

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

既知の問題

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

アップグレード オプションを構成する

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

• 選択的なノードプールのアップグレード: 特定のワーカー ノードプールをクラスタの残りの部分とは別にアップグレードします。

• 並列アップグレード: ノードのグループまたはノードプールを同時にアップグレードするようにアップグレード プロセスを構成します。

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

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

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

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

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

• ワーカーノード全体をアップグレードする前に、ワーカーノードのサブセットをアップグレードして正常に動作することを確認する: ワーカー ノードプールを選択してアップグレードすると、アップグレードされたノードプールでワークロードが正しく実行されていることを確認してから、残りのノードプールをアップグレードできます。

• メンテナンスの時間枠を短縮する: 大規模なクラスタのアップグレードは時間がかかる場合があり、アップグレードが完了する正確な時間を予測することは困難です。クラスタのアップグレード時間は、アップグレードするノードの数に比例します。ノードプールを除外して、アップグレードするノード数を減らすと、アップグレード時間を短縮できます。アップグレードは複数回に分けて実施することになりますが、メンテナンスの時間枠を短くすることで、時間が予測可能になり、スケジューリングがしやすくなります。

ノードプールのバージョン スキュー: 2 つ前までのマイナー バージョン

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

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

たとえば、バージョン 1.28 クラスタを使用している場合、ワーカー ノードプールをバージョン 1.28、1.16、または 1.15 バージョンで作成できます。クラスタをバージョン 1.29 にアップグレードする場合、まず、バージョン 1.15 のワーカー ノードプールをバージョン 1.28 のクラスタでサポートされているバージョンにアップグレードする必要があります。バージョン 1.16 のワーカー ノードプールは、クラスタをバージョン 1.29 にアップグレードする前にバージョン 1.28 にアップグレードする必要はありません。クラスタをバージョン 1.29 にアップグレードした後に、バージョン 1.16 のワーカー ノードプールをバージョン 1.29 にアップグレードする場合は、バージョン 1.28 をスキップして 1.29 に直接アップグレードできます。

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

1.29

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

この機能はパブリック プレビューから一般提供に移行中のため、次の状況では、ハイブリッド クラスタに対して引き続きプレビュー アノテーションが必要になります。バージョン 1.28.x のハイブリッド クラスタにバージョン 1.16.y のワーカー ノードプールがある場合は、バージョン 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

プレビュー

このプロダクトまたは機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 一般提供前のプロダクトと機能は「現状のまま」ご利用いただけますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

ワーカー ノードプールに対する 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.28.0 で、2 つのワーカー ノードプール（wpool01 と wpool02）があるとします。また、コントロール プレーンと wpool01 は 1.29.100-gke.251 にアップグレードしますが、wpool02 はバージョン 1.28.0 のままにするとします。

この部分的なアップグレードを行うには、次のクラスタ構成ファイルの例のように、クラスタ構成を変更します。

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.29.200-gke.243
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.29.200-gke.243
  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.28.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 を現在の（アップグレード後の）クラスタ バージョンに設定します。

   アップグレードの対象として複数のワーカー ノードプールが選択されている場合、Cluster 仕様の spec.nodePoolUpgradeStrategy.concurrentNodePools の値により、並列でアップグレードされるノードプールの数が決まります。これらのワーカー ノードプールを同時にアップグレードしない場合は、アップグレードするノードプールを 1 つずつ選択します。

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

   クラスタのアップグレード オペレーションでは、以前にアップグレードから除外され、anthosBareMetalVersion が現在の（アップグレード後の）クラスタ バージョンに設定されているワーカー ノードプールだけがアップグレードされます。

たとえば、クラスタをバージョン 1.29.100-gke.251 にアップグレードし、ノードプール wpool02 はアップグレード前の古いクラスタ バージョン 1.28.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.29.200-gke.243
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.29.200-gke.243
  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

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

プレビュー

このプロダクトまたは機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 一般提供前のプロダクトと機能は「現状のまま」ご利用いただけますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

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

ノードプールのロールバック機能は、バージョン 1.29 クラスタ（バージョン 1.29 のコントロール プレーン ノードのあるクラスタ）でプレビュー版として利用できます。この機能はプレビュー版のため、機能を有効にするには、Cluster リソースに preview.baremetal.cluster.gke.io/worker-node-pool-upgrade-rollback: enable アノテーションを追加する必要があります。

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

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.28.700-gke.150
     nodes:
     - address:  10.200.0.1
     - address:  10.200.0.2
     - address:  10.200.0.3
     ...
   

   ロールバックの対象として複数のワーカー ノードプールが選択されている場合、Cluster 仕様の 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 ファイルのパス。

   ロールバックが自動的に開始します。

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

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

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

クラスタ構成ファイルを編集するときに、bmctl update と kubectl apply -f を同じものとして使用しないでください。これらのコマンドを同じものとして使用すると、入力された内容が Cluster 仕様のヘッダーによって意図せず削除される可能性があります。たとえば、bmctl update を使用してクラスタ構成ファイルを更新し、レジストリ ミラーを構成できます。調整後に、クラスタに spec.nodeConfig.registryMirrors が設定されます。

その後、kubectl apply -f コマンドを使用してクラスタ構成を変更すると、クラスタの reconciler によって入力された spec.nodeConfig.registryMirrors が削除されます。この現象は、クラスタ構成仕様にない構成がクラスタに存在するために発生します。

kubectl

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

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

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

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

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

   • CLUSTER_NAMESPACE: ノードプールがデプロイされている 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.28.700-gke.150
     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 の値がターゲット ロールバック バージョンに設定されます。

並列アップグレード

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

注意: Portworx などのマネージド データ サービスを利用してクラスタのステートフル ワークロードを管理している場合は、並列アップグレードを行わないことをおすすめします。

クラスタのアップグレードが高速化される並列アップグレートには、次の 2 つの方法があります。

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

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

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

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

重要: 並列アップグレードでは、Pod Disruption Budget（PDB）は考慮されません。中断の影響を受けやすいワークロードには minimumAvailableNodes フィールドを使用することをおすすめします。アップグレード プロセス全体で、ワークロードを実行できるノードの最小数を指定できます。

ノードのアップグレード方法は、ワーカー ノードプールにのみ適用されます。コントロール プレーンとロードバランサのノードプールには、ノードのアップグレード方法を指定できません。コントロール プレーンとロードバランサのノードプール内のノードは、クラスタのアップグレードで 1 つずつアップグレードされます。コントロール プレーン ノードプールとロードバランサ ノードプールは、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 

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

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

コントロール プレーン ノードプールとロード バランシング ノードプールは、この設定の影響を受けません。これらのノードプールは常に 1 つずつ順番にアップグレードされます。コントロール プレーン ノードプールとロードバランサ ノードプールは、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.29.200-gke.243
     ...
     nodePoolUpgradeStrategy:
       concurrentNodePools: 0
     ...
   

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

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

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

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

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

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

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

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

注: 関連するユーザー クラスタをアップグレードする前に、管理クラスタをアップグレードする必要があります。ただし、管理クラスタを 1.29.200-gke.243 にアップグレードする前に、関連するユーザー クラスタがバージョン 1.28.0 以降であることを確認してください。bmctl は、バージョンが 1.28.0 より前のユーザー クラスタを検出すると、エラーを出力します。

bmctl

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

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

2. クラスタ構成ファイルの 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.29.200-gke.243
   

3. 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.29

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

Google Distributed Cloud 1.28

プレビュー

このプロダクトまたは機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 一般提供前のプロダクトと機能は「現状のまま」ご利用いただけますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

アップグレードの一時停止と再開機能はプレビュー版ですが、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 フィールドは変更可能です。いつでも追加または更新できます。

アップグレードを一時停止する

クラスタのアップグレードを一時停止するには、Cluster 仕様の 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 です。