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

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

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

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

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

おすすめの方法

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

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

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

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

既知の問題

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • NodePool 仕様の anthosBareMetalVersion をクラスタ ターゲットのアップグレード バージョンに設定します。
    • NodePool 仕様の anthosBareMetalVersion フィールドを省略するか、空の文字列に設定します。デフォルトでは、ワーカー ノードプールはクラスタのアップグレードに含まれています。
  2. アップグレードから除外するワーカー ノードプールについて、anthosBareMetalVersion をクラスタの現在の(アップグレード前の)バージョンに設定します。

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

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

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

たとえば、クラスタのバージョンが 1.15.0 で、2 つのワーカー ノードプール(wpool01wpool02)があるとします。また、コントロール プレーンと wpool01 を 1.16.8 にアップグレードするが、wpool02 はバージョン 1.15.0 に維持するとします。

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

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.16.8
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.16.8
  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.15.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.16.8 にアップグレードしたが、ノードプール wpool02 はアップグレード前の古いクラスタ バージョン 1.15.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.16.8
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.16.8
  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

並列アップグレード

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

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

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

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

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

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

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

コントロール プレーンとロード バランシングのノードプールは、この設定の影響を受けません。これらのノードプールは常に一つずつ順番にアップグレードされます。コントロール プレーンのノードプールとロードバランサ ノードプールは、クラスタ仕様(controlPlane.nodePoolSpec.nodesloadBalancer.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.16.8
      ...
      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.16.8
    
  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 が必要です。