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

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.200-gke.243 を使用している場合は、クラスタをバージョン 1.29.200-gke.243 にのみアップグレードできます。

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

マイナー バージョンは、より上位のパッチ バージョンにアップグレードできます。つまり、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.700-gke.150 から 1.29.200-gke.243 にアップグレードできます。

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

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

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

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

1.29

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

  • （1.29 一般提供）ワーカー ノードプールとクラスタの間の最大バージョン スキューは、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.200-gke.243
  • 1.29.200-gke.243
  • 1.29.100-gke.251
  • 1.29.0-gke.1449
  • 1.28.500-gke.120
  • 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.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.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.700-gke.150
  • 1.28.700-gke.150
  • 1.28.600-gke.163
  • 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.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.28.600-gke.163
  • 1.28.600-gke.163
  • 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.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.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.10
  • 1.16.10
  • 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.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 の一般提供として利用できます。

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

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

次のステップ