GKE on Bare Metal クラスタをアップグレードする場合、アップグレード プロセスには複数のステップとコンポーネントが含まれます。アップグレード ステータスのモニタリングや、問題の診断とトラブルシューティングを行う際に、bmctl upgrade cluster コマンドを実行した場合に起こる内容を把握することが有効です。このドキュメントでは、クラスタのアップグレードのコンポーネントとステージについて詳しく説明します。
概要
アップグレード プロセスにより、GKE on Bare Metal クラスタを現在のバージョンから上位のバージョンに移行します。
このバージョン情報は、管理クラスタのクラスタ カスタム リソースの一部として、次の場所に保存されます。
status.anthosBareMetalVersion: クラスタの現在のバージョンを定義します。spec.anthosBareMetalVersion: ターゲット バージョンを定義します。アップグレード プロセスの実行の開始時に設定されます。
アップグレード オペレーションが成功すると、ターゲット バージョンが spec.anthosBareMetalVersion から status.anthosBareMetalVersion に調整されます。
バージョン スキュー
バージョン スキューとは、管理クラスタとその管理対象のユーザー クラスタのバージョンの違いのことです。GKE on Bare Metal クラスタは、Kubernetes と同じスタイルに従います。管理クラスタは、マネージド クラスタよりも最大で 1 つ新しいマイナー バージョンにできます。
アップグレードのバージョン ルール
新しいバージョンの bmctl をダウンロードしてインストールすると、bmctl の以前のバージョンで作成またはアップグレードされた管理者、ハイブリッド、スタンドアロン、ユーザー クラスタをアップグレードできます。クラスタを下位バージョンにダウングレードすることはできません。
クラスタは、使用している bmctl のバージョンと一致するバージョンにのみアップグレードできます。つまり、bmctl のバージョン 1.15.11 を使用している場合は、クラスタをバージョン 1.15.11 にのみアップグレードできます。
パッチ バージョンのアップグレード
任意のマイナー バージョンについて、より上位のパッチ バージョンにアップグレードできます。つまり、Y が X より大きい限り、1.15.X バージョン クラスタをバージョン 1.15.Y にアップグレードできます。たとえば、1.14.0 から 1.14.1 にアップグレードしたり、1.14.1 から 1.14.3 にアップグレードしたりできます。クラスタに最新のセキュリティ修正が適用されているように、可能な限り最新のパッチ バージョンにアップグレードすることをおすすめします。
マイナー バージョンのアップグレード
パッチ バージョンに関係なく、クラスタをマイナー バージョン間でアップグレードできます。つまり、1.N.X がお使いのクラスタのバージョンで、N+1 が次に使用可能なマイナー バージョンであれば、1.N.X から 1.N+1.Y にアップグレードできます。この場合、パッチ バージョン X と Y はアップグレード ロジックに影響しません。たとえば、1.14.3 から 1.15.11 にアップグレードできます。
クラスタのアップグレードでは、マイナー バージョンをスキップすることはできません。クラスタのバージョンから 2 つ以上離れたマイナー バージョンにアップグレードしようとすると、bmctl がエラーを出力します。たとえば、バージョン 1.13.0 のクラスタをバージョン 1.15.0 にアップグレードすることはできません。
管理クラスタは、同じマイナー バージョンまたは以前のマイナー バージョンのユーザー クラスタを管理できます。マネージド ユーザー クラスタは、管理クラスタより 1 つ前のマイナー バージョン以降でなければなりません。そのため、管理クラスタを新しいマイナー バージョンにアップグレードする前に、すべてのマネージド ユーザー クラスタが管理クラスタと同じマイナー バージョンであることを確認してください。
次のアップグレード手順の例では、バージョン 1.14.2 から GKE on Bare Metal 1.15.11 へのアップグレード プロセスを示しています。
コンポーネントをアップグレードする
コンポーネントは、ノードとクラスタの両方のレベルでアップグレードされます。クラスタレベルでは、次のコンポーネントがアップグレードされます。
- ネットワーキング、オブザーバビリティ、ストレージのクラスタ コンポーネント。
- 管理クラスタ、ハイブリッド クラスタ、スタンドアロン クラスタの場合、ライフサイクル コントローラ。
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カスタム リソースを作成します。- このプリフライト チェックでは、クラスタのアップグレード チェック、ネットワーク ヘルスチェック、ノード ヘルスチェックなどの追加チェックが実行されます。
- これらの追加チェックの結果が結合され、クラスタがターゲット バージョンに正常にアップグレードできるかどうかが報告されます。
プリフライト チェックが成功し、ブロックの問題がない場合は、次の図のように、クラスタ内のコンポーネントが指定された順序でアップグレードされます。
上の図では、コンポーネントが次の順番でアップグレードされます。
- アップグレードは、
spec.anthosBareMetalVersionフィールドの更新から始まります。 - コントロール プレーンのロードバランサがアップグレードされます。
- コントロール プレーンのノードプールがアップグレードされます。
- 同時に、GKE 接続がアップグレードされ、クラスタ アドオンがアップグレードされ、ロードバランサ ノードプールがアップグレードされます。
- ロードバランサのノードプールが正常にアップグレードされると、ワーカー ノードプールがアップグレードされます。
すべてのコンポーネントがアップグレードされると、クラスタのヘルスチェックが実行されます。
すべてのチェックに合格するまで、ヘルスチェックの実行が継続されます。
すべてのヘルスチェックに合格すると、アップグレードが終了します。
各コンポーネントには、クラスタ カスタム リソース内に独自のステータス フィールドがあります。これらのフィールドのステータスを確認して、アップグレードの進行状況を確認できます。
| シーケンス | フィールド名 | 意味 |
|---|---|---|
| 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 の新しいバージョンがデプロイされます。
ユーザー クラスタのアップグレードと同様に、Cluster.spec.anthosBareMetalVersion フィールドを目的のバージョンに更新してアップグレード プロセスを開始します。次の図に示すように、コンポーネントが更新される前に 2 つの追加のステップが実行されます。lifecycle-controller-manager は、目的のバージョンに自身をアップグレードしてから、目的のバージョンの anthos-cluster-operator をデプロイします。この anthos-cluster-operator は、アップグレード プロセスの残りのステップを実行します。
成功すると、anthos-cluster-operator によってターゲット バージョンが spec.anthosBareMetalVersion から status.anthosBareMetalVersion に整合されます。
ブートストラップ クラスタを使用したアップグレード
管理クラスタ、ハイブリッド クラスタ、スタンドアロン クラスタをアップグレードするプロセスは、前のセクションで説明したユーザー クラスタと類似しています。
主な違いは、bmctl upgrade cluster コマンドによって、ブートストラップ クラスタを作成するプロセスが開始されることです。このブートストラップ クラスタは、アップグレード中にハイブリッド クラスタ、管理クラスタ、スタンドアロン クラスタを管理する一時的なクラスタです。
クラスタの管理所有権をブートストラップ クラスタに移行するプロセスを、ピボットといいます。残りのアップグレードは、ユーザー クラスタのアップグレードと同じプロセスで行われます。
アップグレード プロセス中、ターゲット クラスタ内のリソースは古いままです。 アップグレードの進行状況は、ブートストラップ クラスタのリソースにのみ反映されます。
必要に応じて、ブートストラップ クラスタにアクセスしてアップグレード プロセスのモニタリングとデバッグを行うことができます。ブートストラップ クラスタには bmctl-workspace/.kindkubeconfig を使用してアクセスできます。
アップグレードの完了後にクラスタの管理所有権を元に戻すには、クラスタがブートストラップ クラスタからアップグレードされたクラスタにリソースをピボットします。アップグレード プロセス中にクラスタをピボットするための手動のステップはありません。クラスタのアップグレードに成功すると、ブートストラップ クラスタが削除されます。
ノードのドレイン
GKE on Bare Metal クラスタをアップグレードすると、ノードがドレインされるため、アプリケーションの中断が発生する可能性があります。このドレイン プロセスにより、ノード上で実行されているすべての Pod がシャットダウンされ、クラスタ内の残りのノードで再起動します。
Deployment は、そのような中断を許容するために使用できます。Deployment では、アプリケーションまたはサービスの複数のレプリカの実行を指定できます。複数のレプリカを使用するアプリケーションでは、アップグレード中に中断がほとんど、またはまったく発生しません。
Pod Disruption Budget（PDB）
Pod Disruption Budget（PDB）を使用すると、定義された数のレプリカが常に通常の実行条件でクラスタで実行されるようにできます。PDB を使用すると、Pod を再スケジュールする必要がある場合に中断をワークロードに制限できます。ただし、アップグレード中にノードがドレインされても、GKE on Bare Metal は PDB の設定に従いません。ノードのドレイン プロセスはベスト エフォートです。一部の Pod が Terminating 状態から先に進まず、ノードを空にしないことがあります。ノードのドレイン プロセスに 20 分以上かかる場合、停止した Pod があってもアップグレードは続行されます。