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

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

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

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

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

おすすめの方法

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

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

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

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

既知の問題

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

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

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

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

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

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

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

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

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

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

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

バージョン 1.28 以降のクラスタでは、ワーカー ノードプールのバージョンは、クラスタ（コントロール プレーン）のバージョンより最大 2 低いマイナー バージョンにできます。ワーカー ノードプールに対するこの n-2 バージョン スキューのサポートにより、フリートのアップグレードをより柔軟に計画できます。たとえば、クラスタをバージョン 1.29 にアップグレードする前に、すべてのバージョン 1.16 ワーカー ノードプールをバージョン 1.28 にアップグレードする必要はありません。

ベアメタル版 GKE

リリース 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
...

ベアメタル版 GKE

ワーカー ノードプールの 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.0-gke.1449 にアップグレードするものの、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.0-gke.1449
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.29.0-gke.1449
  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 を現在の（アップグレード後の）クラスタ バージョンに設定します。

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

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

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

たとえば、クラスタはバージョン 1.29.0-gke.1449 にアップグレードしたが、ノードプール 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.0-gke.1449
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.29.0-gke.1449
  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.29 クラスタ（バージョン 1.29 のコントロール プレーン ノードを持つクラスタ）のプレビューで使用できます。この機能がプレビュー版である間、この機能を有効にするには、preview.baremetal.cluster.gke.io/worker-node-pool-upgrade-rollback: enable アノテーションを Cluster リソースに追加する必要があります。

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

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.500-gke.120
  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 ファイルのパス。

    ロールバックは自動的に開始されます。

  3. ロールバックが実行されると、GKE on Bare Metal はノードごとに次のアクティビティを実行します。

    • ノードをメンテナンス モードにします。
    • ノード上でリセットジョブを実行して、ノードをクリーンな状態にします。
    • ノードでマシンのプリフライト チェックを実行します。
    • ノードで 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: ノードプールがデプロイされている名前空間の名前。これはクラスタの名前空間です。

    • 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.500-gke.120
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...

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

    ロールバックは自動的に開始されます。

  4. ロールバックが実行されると、GKE on Bare Metal はノードごとに次のアクティビティを実行します。

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

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

並列アップグレード

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

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

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

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

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

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

ノードのアップグレード方法は、ワーカー ノードプールにのみ適用されます。コントロール プレーンやロードバランサのノードプールにノードのアップグレード方法は指定できません。クラスタのアップグレード中は、コントロール プレーンとロードバランサのノードプール内のノードが一つずつアップグレードされます。コントロール プレーンのノードプールとロードバランサ ノードプールは、クラスタ仕様（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 に設定すると、クラスタ内のすべてのワーカー ノードプールが並行してアップグレードされます。

コントロール プレーンとロード バランシングのノードプールは、この設定の影響を受けません。これらのノードプールは常に一つずつ順番にアップグレードされます。コントロール プレーンのノードプールとロードバランサ ノードプールは、クラスタ仕様（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. クラスタ構成ファイルのクラスタ仕様に 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.0-gke.1449
  ...
  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. GKE on Bare Metal のダウンロードの説明に沿って、最新の 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.0-gke.1449

  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 以降であるクラスタで一般提供されています。

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

  • アップグレード中にクラスタ ワークロードになんらかの問題があったため、アップグレードを一時停止して問題を調査する必要がある

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

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

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

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

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

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

GKE on Bare Metal 1.29

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

GKE on Bare Metal 1.28

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

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

  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 が長時間実行されると、最終的にタイムアウトします。

一時停止したアップグレードを再開する

クラスタ仕様で 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

    この例では、ノードは GKE on Bare Metal バージョン 1.16.2 です。