クラスタ アップグレードのライフサイクルとステージ

Google Distributed Cloud をアップグレードする場合、アップグレード プロセスには複数のステップとコンポーネントが含まれます。アップグレード ステータスのモニタリングや、問題の診断とトラブルシューティングを行う際に、bmctl upgrade cluster コマンドを実行した場合に起こる内容を把握することが有効です。このドキュメントでは、クラスタのアップグレードのコンポーネントとステージについて詳しく説明します。

概要

アップグレード プロセスにより、Google Distributed Cloud クラスタが現在のバージョンから上位のバージョンに移行します。

このバージョン情報は、管理クラスタのクラスタ カスタム リソースの一部として、次の場所に保存されます。

  • status.anthosBareMetalVersion: クラスタの現在のバージョンを定義します。

  • spec.anthosBareMetalVersion: ターゲット バージョンを定義します。アップグレード プロセスの実行の開始時に設定されます。

アップグレード オペレーションが成功すると、status.anthosBareMetalVersion が spec.anthosBareMetalVersion に調整され、両方のターゲット バージョンが表示されます。

クラスタ バージョン スキュー

クラスタ バージョン スキューは、管理するクラスタ（ハイブリッドまたは管理）と、そのマネージド ユーザー クラスタのバージョンの違いです。ユーザー クラスタを追加またはアップグレードする場合、次のバージョン ルールが適用されます。

1.29

バージョン 1.29 の管理クラスタまたはハイブリッド クラスタによって管理されるユーザー クラスタには、次のルールが適用されます。

  • ユーザー クラスタのバージョンは、管理クラスタ（管理またはハイブリッド）のバージョンよりも大きくすることはできません。

  • （1.29 プレビュー）ユーザー クラスタは、管理クラスタのバージョンより 2 つ前のマイナー バージョンまで低いバージョンにできます。たとえば、バージョン 1.29 の管理クラスタは、1.16 のユーザー クラスタを管理できます。この n-2 バージョン スキュー管理は、バージョン 1.29 のクラスタを管理するためのプレビュー機能として利用できます。

  • （1.29 プレビュー）特定の管理クラスタについては、ユーザー クラスタのマイナー バージョンが同じである必要はありません。たとえば、バージョン 1.29 の管理クラスタは、バージョン 1.29、バージョン 1.28、バージョン 1.16 のユーザー クラスタを管理できます。この混合バージョン スキュー管理は、バージョン 1.29 でクラスタを管理するためのプレビュー機能として利用できます。

    プレビューのマルチスキュー管理機能を使用すると、フリートのアップグレードを柔軟に計画できます。たとえば、管理クラスタをバージョン 1.29 にアップグレードする前に、すべてのバージョン 1.16 のユーザー クラスタをバージョン 1.28 にアップグレードする必要はありません。

1.28 以前

バージョン 1.28 以前の管理クラスタまたはハイブリッド クラスタで管理されているユーザー クラスタには、次のルールが適用されます。

  • ユーザー クラスタのバージョンは、管理クラスタ（管理またはハイブリッド）のバージョンよりも大きくすることはできません。

  • ユーザー クラスタは、管理クラスタのバージョンより 1 つ前のマイナー バージョンまで使用できます。たとえば、バージョン 1.28 の管理クラスタは、バージョン 1.15 のユーザー クラスタを管理することはできません。

  • 特定の管理クラスタの、すべてのマネージド ユーザー クラスタが同じマイナー バージョンである必要があります。

ノードプールのバージョン スキュー ルールについては、ノードプールのバージョニング ルールをご覧ください。

バージョン ルール

新しいバージョンの bmctl をダウンロードしてインストールすると、bmctl の以前のバージョンで作成またはアップグレードされた管理者、ハイブリッド、スタンドアロン、ユーザー クラスタをアップグレードできます。クラスタを下位バージョンにダウングレードすることはできません。

クラスタは、使用している bmctl のバージョンと一致するバージョンにのみアップグレードできます。つまり、bmctl のバージョン 1.29.100-gke.251 を使用している場合は、クラスタをバージョン 1.29.100-gke.251 にのみアップグレードできます。

パッチ バージョンのアップグレード

任意のマイナー バージョンについて、より上位のパッチ バージョンにアップグレードできます。つまり、Y が X より大きい限り、1.29.X バージョン クラスタをバージョン 1.29.Y にアップグレードできます。たとえば、1.28.0 から 1.28.100 にアップグレードしたり、1.28.100 から 1.28.300 にアップグレードしたりできます。クラスタに最新のセキュリティ修正が適用されているように、可能な限り最新のパッチ バージョンにアップグレードすることをおすすめします。

マイナー バージョンのアップグレード

パッチ バージョンに関係なく、クラスタをマイナー バージョン間でアップグレードできます。つまり、1.N.X がお使いのクラスタのバージョンで、N+1 が次に使用可能なマイナー バージョンであれば、1.N.X から 1.N+1.Y にアップグレードできます。この場合、パッチ バージョン X と Y はアップグレード ロジックに影響しません。たとえば、1.28.500-gke.120 から 1.29.100-gke.251 にアップグレードできます。

クラスタのアップグレードでは、マイナー バージョンをスキップすることはできません。クラスタのバージョンから 2 つ以上離れたマイナー バージョンにアップグレードしようとすると、bmctl がエラーを出力します。たとえば、バージョン 1.16.0 のクラスタをバージョン 1.29.0 にアップグレードすることはできません。

管理クラスタは、同じマイナー バージョンまたは以前のマイナー バージョンのユーザー クラスタを管理できます。マネージド ユーザー クラスタは、管理クラスタより 1 つ前のマイナー バージョン以降でなければなりません。そのため、管理クラスタを新しいマイナー バージョンにアップグレードする前に、すべてのマネージド ユーザー クラスタが管理クラスタと同じマイナー バージョンであることを確認してください。

ノードプールのバージョニング ルール

ノードプールを個別にアップグレードする場合、次のバージョン ルールが適用されます。

1.29

  • クラスタ バージョンは、ワーカー ノードプールのバージョン以上である必要があります。

  • （1.29 GA）ワーカー ノードプールとクラスタの間の最大バージョン スキューは、2 つのマイナー バージョンです。

  • ワーカー ノードプールのバージョンは、クラスタのバージョンより新しいバージョンにすることはできません。過去のリリースには、後続のリリースの包括的な詳細がありません。これは、互換性を確保するための要件です。

    たとえば、バージョン 1.16.6 はバージョン 1.28.100-gke.146 のリリース後にリリースされたため、クラスタをバージョン 1.16.6 からバージョン 1.28.100-gke.146 にアップグレードしてワーカー ノードプールをバージョン 1.16.6 のままにすることはできません。同様に、クラスタをバージョン 1.28.100-gke.146 にアップグレードするが、ワーカー ノードプールをバージョン 1.16.5 のままにする場合は、クラスタがバージョン 1.28.100-gke.146 のときは、ワーカー ノードプールをバージョン 1.16.6 にアップグレードできません。

1.28

  • クラスタ バージョンは、ワーカー ノードプールのバージョン以上である必要があります。

  • （1.28 プレビュー）n-2 バージョン スキューのプレビュー機能を有効にすると、ワーカー ノードプールとクラスタの間の最大バージョン スキューは 2 つのマイナー バージョンになります。この機能を有効にしない場合、ワーカー ノードプールとクラスタの間の最大バージョン スキューは、1 マイナー バージョンです。

  • ワーカー ノードプールを、クラスタ バージョンより時系列にリリースされたバージョンにすることはできません。過去のリリースには、後続のリリースの包括的な詳細がありません。これは、互換性を確保するための要件です。

    たとえば、バージョン 1.16.6 はバージョン 1.28.100-gke.146 のリリース後にリリースされたため、クラスタをバージョン 1.16.6 からバージョン 1.28.100-gke.146 にアップグレードしてワーカー ノードプールをバージョン 1.16.6 のままにすることはできません。同様に、クラスタをバージョン 1.28.100-gke.146 にアップグレードするが、ワーカー ノードプールをバージョン 1.16.5 のままにする場合は、クラスタがバージョン 1.28.100-gke.146 のときは、ワーカー ノードプールをバージョン 1.16.6 にアップグレードできません。

1.16

  • クラスタ バージョンは、ワーカー ノードプールのバージョン以上である必要があります。

  • ワーカー ノードプールとクラスタの間の最大バージョン スキューは、1 マイナー バージョンです。

  • ワーカー ノードプールを、クラスタ バージョンより時系列にリリースされたバージョンにすることはできません。過去のリリースには、後続のリリースの包括的な詳細がありません。これは、互換性を確保するための要件です。

    たとえば、バージョン 1.16.6 はバージョン 1.28.100-gke.146 のリリース後にリリースされたため、クラスタをバージョン 1.16.6 からバージョン 1.28.100-gke.146 にアップグレードしてワーカー ノードプールをバージョン 1.16.6 のままにすることはできません。同様に、クラスタをバージョン 1.28.100-gke.146 にアップグレードするが、ワーカー ノードプールをバージョン 1.16.5 のままにする場合は、クラスタがバージョン 1.28.100-gke.146 のときは、ワーカー ノードプールをバージョン 1.16.6 にアップグレードできません。

次の表に、特定のクラスタ バージョンで許可されている、サポートされているノードプールのバージョンを示します。

1.29

クラスタ（コントロール プレーン）のバージョン サポートされているワーカー ノードプールのバージョン
1.29.100-gke.251
  • 1.29.100-gke.251
  • 1.29.0-gke.1449
  • 1.28.400-gke.77
  • 1.28.300-gke.136
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.435
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
1.29.0-gke.1449
  • 1.29.0-gke.1449
  • 1.28.300-gke.136
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.435
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0

1.28

クラスタ（コントロール プレーン）のバージョン サポートされているワーカー ノードプールのバージョン
1.28.500-gke.120
  • 1.28.500-gke.120
  • 1.28.400-gke.77
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.400-gke.77
  • 1.28.400-gke.77
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.300-gke.131
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.200-gke.118
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.100-gke.146
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.0-gke.425
  • 1.28.0-gke.425
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0

     

     

     

1.16

クラスタ（コントロール プレーン）のバージョン サポートされているワーカー ノードプールのバージョン
1.16.9
  • 1.16.9
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.8
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.7
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.6
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.5
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.4
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.3
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.2
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.1
  • 1.16.1
  • 1.16.0
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.0
  • 1.16.0
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0

コンポーネントをアップグレードする

コンポーネントは、ノードとクラスタの両方のレベルでアップグレードされます。クラスタレベルでは、次のコンポーネントがアップグレードされます。

  • ネットワーキング、オブザーバビリティ、ストレージ用のクラスタ コンポーネント。
  • 管理クラスタ、ハイブリッド クラスタ、スタンドアロン クラスタの場合、ライフサイクル コントローラ。
  • gke-connect-agent。

クラスタ内のノードは、次のいずれかのロールとして実行されます。ノードロールに応じて、異なるコンポーネントがアップグレードされます。

ノードのロール 関数 アップグレードするコンポーネント
ワーカー ユーザー ワークロードを実行する Kubelet、コンテナ ランタイム（Docker または containerd）
コントロール プレーン Kubernetes コントロール プレーン、クラスタ ライフサイクル コントローラ、Google Kubernetes Engine（GKE）Enterprise エディション プラットフォーム アドオンを実行する Kubernetes コントロール プレーンの静的 Pod（kubeapi-server、kube-scheduler、kube-controller-manager、etcd）

lifecycle-controllers-manager および anthos-cluster-operator などのライフサイクル コントローラ

stackdriver-log-aggregator および gke-connect-agent などの Google Kubernetes Engine（GKE）Enterprise エディション プラットフォーム アドオン
コントロール プレーンのロードバランサ kube-apiserver へのトラフィックを処理する HAProxy と Keepalived を実行し、仮想 IP アドレスを申請して MetalLB スピーカーを実行する コントロール プレーン ロードバランサの静的 Pod（HAProxy、Keepalived）

MetalLB スピーカー

ダウンタイムの想定値

次の表に、クラスタをアップグレードする際に予想されるダウンタイムと潜在的な影響を示します。この表は、複数のクラスタノードと HA コントロール プレーンがあることを前提としています。スタンドアロン クラスタを実行している場合、または HA コントロール プレーンがない場合は、追加のダウンタイムが予想されます。特に明記されていない限り、このダウンタイムは管理クラスタとユーザー クラスタのアップグレードの両方に適用されます。

コンポーネント ダウンタイムの想定値 ダウンタイムが発生する場合
Kubernetes コントロール プレーン API サーバー（kube-apiserver）、etcd、スケジューラ ダウンタイムなし 該当なし
ライフサイクル コントローラと ansible-runner ジョブ（管理クラスタのみ） ダウンタイムなし 該当なし
Kubernetes コントロール プレーン loadbalancer-haproxy と keepalived ロードバランサがトラフィックをリダイレクトする際の一時的なダウンタイム（1～2 分未満）。 アップグレード プロセスの開始時。
オブザーバビリティ pipeline-stackdriver と metrics-server オペレータがドレインされ、アップグレードされた。ダウンタイムは 5 分未満となります。

DaemonSet は、ダウンタイムなしで引き続き動作します。		 コントロール プレーン ノードのアップグレード完了後。
Container Network Interface（CNI） 既存のネットワーク ルートのダウンタイムなし。

DaemonSet は、ダウンタイムなしで 2 つずつデプロイされます。

オペレーターはドレインされ、アップグレードされます。5 分未満のダウンタイム。		 コントロール プレーン ノードのアップグレード完了後。
MetalLB（ユーザー クラスタのみ） オペレータがドレインされ、アップグレードされた。ダウンタイムは 5 分未満です。

既存のサービスのダウンタイムなし		 コントロール プレーン ノードのアップグレード完了後。
CoreDNS と DNS オートスケーラー（ユーザー クラスタのみ） CoreDNS にはオートスケーラーを持つ複数のレプリカがあります。通常、ダウンタイムは発生しません。 コントロール プレーン ノードのアップグレード完了後。
ローカル ボリューム プロビジョナー 既存のプロビジョニングされた永続ボリューム（PV）のダウンタイムなし。

オペレータは 5 分間のダウンタイムが発生する可能性があります。		 コントロール プレーン ノードのアップグレード完了後。
Istio / ingress Istio オペレータがドレインされ、アップグレードされます。約 5 分のダウンタイム。

既存の構成済みの Ingress は引き続き動作します。		 コントロール プレーン ノードのアップグレード完了後。
その他のシステム オペレーター ドレインおよびアップグレードされたときに 5 分のダウンタイム。 コントロール プレーン ノードのアップグレード完了後。
ユーザー ワークロード 設定によって異なります（高可用性など）。

独自のワークロード デプロイを確認して、潜在的な影響を把握する。		 ワーカーノードがアップグレードされるタイミング。

ユーザー クラスタのアップグレードの詳細

このセクションでは、コンポーネントのアップグレードの順序と、ユーザー クラスタのアップグレードのステータス情報について詳しく説明します。次のセクションでは、管理クラスタ、ハイブリッド クラスタ、スタンドアロン クラスタのアップグレードに関する、このフローからの逸脱について詳しく説明します。

次の図は、ユーザー クラスタのアップグレードのプリフライト チェック プロセスを示しています。

クラスタのプリフライト チェックは、アップグレード プロセスが開始する前に、クラスタで追加のヘルスチェックを実行します。

上の図は、アップグレード中に発生するステップの詳細を示しています。

  • bmctl upgrade cluster コマンドは、PreflightCheck カスタム リソースを作成します。
  • このプリフライト チェックでは、クラスタのアップグレード チェック、ネットワーク ヘルスチェック、ノード ヘルスチェックなどの追加のチェックが実行されます。
  • これらの追加チェックの結果が結合され、クラスタがターゲット バージョンに正常にアップグレードできるかどうかが報告されます。

プリフライト チェックが成功し、ブロッキングの問題がない場合は、次の図に示すように、クラスタ内のコンポーネントが指定された順序でアップグレードされます。

コントロール プレーンのロードバランサとコントロール プレーンのノードプールがアップグレードされ、次に GKE 接続、クラスタ アドオン、ロードバランサ ノードプールとワーカー ノードプールがアップグレードされます。

上の図では、コンポーネントが次の順番でアップグレードされます。

  1. アップグレードは、spec.anthosBareMetalVersion フィールドの更新から始まります。
  2. コントロール プレーンのロードバランサがアップグレードされます。
  3. コントロール プレーンのノードプールがアップグレードされます。
  4. 同時に、GKE 接続がアップグレードされ、クラスタ アドオンがアップグレードされ、ロードバランサ ノードプールがアップグレードされます。
    1. ロードバランサ ノードプールが正常にアップグレードされると、ワーカー ノードプールがアップグレードされます。

  5. すべてのコンポーネントがアップグレードされると、クラスタのヘルスチェックが実行されます。

    ヘルスチェックは、すべてのチェックに合格するまで実行され続けます。

  6. すべてのヘルスチェックに合格すると、アップグレードが完了します。

各コンポーネントには、クラスタのカスタム リソース内に独自のステータス フィールドがあります。これらのフィールドのステータスでアップグレードの進行状況を確認できます。

シーケンス フィールド名 意味
1 status.controlPlaneNodepoolStatus ステータスは、コントロール プレーンのノードプールのステータスからコピーされます。このフィールドには、コントロール プレーン ノードプールのノードのバージョンが含まれます。
2 status.anthosBareMetalLifecycleControllersManifestsVersion クラスタに適用される lifecycles-controllers-manager のバージョン。このフィールドは、管理クラスタ、スタンドアロン クラスタ、ハイブリッド クラスタでのみ使用できます。
2 status.anthosBareMetalManifestsVersion 最後に適用されたマニフェストのクラスタのバージョン。
2 status.controlPlaneLoadBalancerNodepoolStatus ステータスは、コントロール プレーンのロードバランサのノードプールのステータスからコピーされます。Cluster.Spec で個別のコントロール プレーン ロードバランサが指定されていない場合、このフィールドは空になります。
3 status.anthosBareMetalVersions バージョンからノード番号への統合バージョン マップ。
4 status.anthosBareMetalVersion アップグレードされたバージョンの最終ステータス。

管理クラスタ、ハイブリッド クラスタ、スタンドアロン クラスタのアップグレードの詳細

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

アップグレードにブートストラップ クラスタの使用はおすすめしませんが、このオプションは使用できます。アップグレード時にブートストラップ クラスタを使用するには、--use-bootstrap=true フラグを指定して bmctl upgrade コマンドを実行します。 アップグレードのステージは、使用する方法によって異なります。

インプレース アップグレード

セルフマネージド クラスタのデフォルトのインプレース アップグレード プロセスは、ユーザー クラスタのアップグレード プロセスと似ています。ただし、インプレース アップグレード プロセスを使用すると、クラスタのプリフライト チェックとヘルスチェックが実行される前に、preflightcheck-operator の新しいバージョンがデプロイされます。

preflightcheck-operator の新しいバージョンは、クラスタのプリフライト チェックがクラスタで追加のヘルスチェックを実行する前にデプロイされます。

ユーザー クラスタのアップグレードと同様に、Cluster.spec.anthosBareMetalVersion フィールドを目的のバージョンに更新してアップグレード プロセスを開始します。次の図に示すように、コンポーネントが更新される前に 2 つの追加のステップが実行されます。lifecycle-controller-manager は、目的のバージョンに自身をアップグレードしてから、目的のバージョンの anthos-cluster-operator をデプロイします。この anthos-cluster-operator は、アップグレード プロセスの残りのステップを実行します。

lifecycle-controller-manager と anthos-cluster-operator は、ユーザー クラスタのコンポーネントと同じ順序で残りのクラスタがアップグレードされる前にデプロイされます。

成功すると、anthos-cluster-operator によってターゲット バージョンが spec.anthosBareMetalVersion から status.anthosBareMetalVersion に整合されます。

ブートストラップ クラスタを使用したアップグレード

管理クラスタ、ハイブリッド クラスタ、スタンドアロン クラスタをアップグレードするプロセスは、前のセクションで説明したユーザー クラスタと類似しています。

主な違いは、bmctl upgrade cluster コマンドによって、ブートストラップ クラスタを作成するプロセスが開始されることです。このブートストラップ クラスタは、アップグレード中にハイブリッド クラスタ、管理クラスタ、スタンドアロン クラスタを管理する一時的なクラスタです。

クラスタの管理所有権をブートストラップ クラスタに移行するプロセスを、ピボットといいます。アップグレードの残りの部分は、ユーザー クラスタのアップグレードと同じプロセスで行われます。

アップグレード プロセス中、ターゲット クラスタ内のリソースは古いままです。 アップグレードの進行状況は、ブートストラップ クラスタのリソースにのみ反映されます。

必要に応じて、ブートストラップ クラスタにアクセスして、アップグレード プロセスのモニタリングとデバッグを行えます。ブートストラップ クラスタには、bmctl-workspace/.kindkubeconfig を介してアクセスできます。

アップグレードの完了後にクラスタの管理所有権を元に戻すには、クラスタがブートストラップ クラスタからアップグレードされたクラスタにリソースをピボットします。アップグレード プロセス中にクラスタをピボットするための手動のステップはありません。ブートストラップ クラスタは、クラスタのアップグレードに成功すると削除されます。

ノードのドレイン

Google Distributed Cloud クラスタをアップグレードすると、ノードがドレインされるため、アプリケーションの停止が発生する可能性があります。このドレイン プロセスにより、ノード上で実行されているすべての Pod がシャットダウンされ、クラスタ内の残りのノードで再起動します。

Deployment を使用すると、このような中断を許容できます。Deployment では、アプリケーションまたはサービスの複数のレプリカの実行を指定できます。複数のレプリカがあるアプリケーションは、アップグレード中に中断がほとんど、またはまったく発生しないはずです。

PodDisruptionBudgets（PDB）

クラスタをアップグレードすると、Google Distributed Cloud はメンテナンス モードのフローを使用してノードをドレインします。

リリース 1.29 以降では、ノードは PodDisruptionBudgets（PDB）を受け入れる Eviction API でドレインされます。PDB を使用すると、定義された数のレプリカが常に通常の実行条件でクラスタで実行されるようにできます。PDB を使用すると、Pod を再スケジュールする必要がある場合に中断をワークロードに制限できます。エビクション ベースのノードドレインは、リリース 1.29 の GA として利用できます。

リリース 1.28 以前では、アップグレード中にノードがドレインされた場合、Google Distributed Cloud は PDB を受け入れません。ノードのドレイン プロセスはベスト エフォートです。一部の Pod が Terminating 状態から先に進まず、ノードを空にしないことがあります。ノードのドレイン プロセスに 20 分を超える時間を要する場合は、停止した Pod が存在してもアップグレードが続行されます。

詳細については、ノードをメンテナンス モードにするをご覧ください。

次のステップ