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

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

GKE on Bare Metal バージョン 1.15.0 以降では、セルフマネージド（管理、ハイブリッド、スタンドアロン）クラスタのデフォルトのアップグレード動作は、インプレース アップグレードです。インプレース アップグレードでは、ブートストラップ クラスタの代わりにライフサイクル コントローラを使用して、アップグレード プロセス全体を管理します。この変更によりプロセスが簡素化され、リソースの要件が縮小されるため、クラスタのアップグレードの信頼性とスケーラビリティが向上します。

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

アップグレードに関する考慮事項

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

おすすめの方法

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

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

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

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

既知の問題

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

管理クラスタ、スタンドアロン クラスタ、ハイブリッド クラスタ、ユーザー クラスタをアップグレードする

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

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.15.11

  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 が必要です。

並列アップグレード

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

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

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

  • ノードプールの同時アップグレード: 複数のノードプールを並列でアップグレードするようにクラスタを構成できます。ワーカー ノードプールのみ並列でアップグレードできます。コントロール プレーンとロードバランサのノードプールは、一つずつアップグレードできます。公開プレビュー版では、複数のノードプールを同時にアップグレードできます。詳細については、ノードプールのアップグレード方法をご覧ください。

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

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

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

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

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

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

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

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: 2
      minimumAvailableNodes: 5

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

複数のワーカー ノードプールが並行してアップグレードするようにクラスタを構成できます。クラスタ仕様の 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.15.0
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...

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

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

ノードの並列アップグレードを無効にする方法

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

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

フィールド デフォルト値 意味
nodePoolUpgradeStrategy.concurrentNodePools（クラスタ仕様） 1 ワーカー ノードプールを順番に（一つずつ）アップグレードします。
upgradeStrategy.parallelUpgrade.concurrentNodes（NodePool 仕様） 1 ノードを順番に（一つずつ）アップグレードします。
upgradeStrategy.parallelUpgrade.minimumAvailableNodes（NodePool 仕様） 0 アップグレード中にノードを利用できるようにする必要はありません。