Version 1.16. This version is no longer supported. For information about how to upgrade to version 1.28, see Upgrade clusters in the latest documentation. For more information about supported and unsupported versions, see the Versioning page in the latest documentation.

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

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

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

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

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

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

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

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

既知の問題

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

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

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

選択的なワーカーノードプールのアップグレード: 特定のワーカーノードプールをクラスタの他の部分とは別にアップグレードします。
並列アップグレード: ノードのグループまたはノードプールを同時にアップグレードするようにアップグレードプロセスを構成します。

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

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

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

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

ワークロードを中断することなくセキュリティ修正を適用するため: コントロールプレーンノード（およびロードバランサノード）のみをアップグレードして、ワーカーノードプールを中断することなく Kubernetes の脆弱性の修正を適用できます。
すべてのワーカーノードをアップグレードする前に、アップグレードされたワーカーノードのサブセットが適切に動作することを確認するため: ワーカーノードプールを選択的にアップグレードして、別のノードプールをアップグレードする前に、アップグレードされたノードプールでワークロードが正しく実行されていることを確認できます。
メンテナンスの時間枠を短縮するため: 大規模なクラスタのアップグレードには時間がかかる場合があり、アップグレードの完了を正確に予測することは困難です。クラスタのアップグレード時間は、アップグレードされるノードの数に比例します。ノードプールを除外して、アップグレードされるノードの数を減らすと、アップグレード時間を短縮できます。アップグレードは複数回行いますが、メンテナンスの時間枠がより小規模で予測しやすいほどスケジューリングに役立ちます。

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

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

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

クラスタのアップグレードに含めるワーカーノードプールの場合は、NodePool 仕様に次のいずれかの変更を加えます。
- NodePool 仕様の anthosBareMetalVersion をクラスタターゲットのアップグレードバージョンに設定します。
- NodePool 仕様の anthosBareMetalVersion フィールドを省略するか、空の文字列に設定します。デフォルトでは、ワーカーノードプールはクラスタのアップグレードに含まれています。
アップグレードから除外するワーカーノードプールについて、anthosBareMetalVersion をクラスタの現在の（アップグレード前の）バージョンに設定します。
クラスタのアップグレードを開始するの説明に沿って、アップグレードを続行します。

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

たとえば、クラスタのバージョンが 1.15.0 で、2 つのワーカーノードプール（wpool01 と wpool02）があるとします。また、コントロールプレーンと 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 フィールドが以前の（アップグレード前の）クラスタバージョンに設定されています。

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

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

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

クラスタアップグレードオペレーションは、以前に 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.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
  ...

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

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

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

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 ノードをワークロードに使用できる必要があります。

注: コントロールプレーンやロードバランサのノードプールのノードアップグレード方法は指定できません。
クラスタ構成ファイルのクラスタ仕様に 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 仕様で定義されています。
前の管理クラスタ、スタンドアロンクラスタ、ハイブリッドクラスタ、ユーザークラスタをアップグレードするのセクションの説明に沿ってクラスタをアップグレードします。

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

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

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

フィールド	デフォルト値	意味
`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 については、クラスタを同じバージョンにのみアップグレードできます。

GKE on Bare Metal のダウンロードの説明に沿って、最新の bmctl をダウンロードします。
クラスタ構成ファイルの 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
```
bmctl upgrade cluster コマンドを使用してアップグレードを完了します。
```
bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
以下を置き換えます。
- CLUSTER_NAME: アップグレードするクラスタの名前。
- ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。
クラスタアップグレードオペレーションは、プリフライトチェックを実行して、クラスタのステータスとノードの健全性を検証します。プリフライトチェックに失敗した場合、クラスタのアップグレードは続行されません。トラブルシューティング情報については、クラスタのインストールやアップグレードに関する問題のトラブルシューティングをご覧ください。

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

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

`kubectl`

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

クラスタ構成ファイルを編集して、anthosBareMetalVersion をアップグレード先のターゲットバージョンに設定します。
アップグレードを開始するには、次のコマンドを実行します。
```
kubectl apply -f CLUSTER_CONFIG_PATH
```
CLUSTER_CONFIG_PATH は、編集したクラスタ構成ファイルへのパスに置き換えます。

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

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

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

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

おすすめの方法

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