TKG サービス クラスタでは、ローリング アップデート モデルがサポートされます。クラスタ仕様を変更すると、ローリング アップデートを開始できます。一部のシステム操作でローリング アップデートが開始される場合があります。環境をアップデートする前に、ローリング アップデート プロセスについて理解しておく必要があります。
TKG サービス 3.0 以降の TKGS クラスタのローリング アップデート モデル
TKG サービス 3.0 以降では、TKG コントローラが vCenter Server とスーパーバイザーから独立しています。TKG サービス の使用を参照してください。これらのコンポーネントをアップグレードしても、TKGS クラスタのローリング アップデートは開始されません。
TKG サービス バージョンをアップグレードすると、TKGS クラスタのローリング アップデートがトリガされる場合があります。
TKG サービス 3.0 より前の TKGS クラスタのローリング アップデート モデル
TKG コントローラは、スーパーバイザー で実行されます。スーパーバイザー をアップデートすると、アップデートが可能な場合は TKG コントローラが自動的にアップデートされます。各 TKG コントローラのアップデートには、CNI、CSI、CPI などのサポート サービスのアップデートと、クラスタの構成のアップデートが含まれる可能性があります。互換性を維持するために、システムは事前チェックを実行し、コンプライアンスを適用します。
vSphere IaaS control plane では、ローリング アップデート モデルを使用して、スーパーバイザー 上の TKG クラスタをアップデートします。ローリング アップデート モデルを使用すると、クラスタをアップデートしている間のダウンタイムを最小限に抑えられます。ローリング アップデートには、Kubernetes ソフトウェアのバージョンのアップグレードに加えて、仮想マシンの構成とリソース、サービスと名前空間、カスタム リソースなどの、クラスタをサポートするインフラストラクチャおよびサービスの更新が含まれます。アップデートが正常に実行されるためには、構成がいくつかの互換性要件を満たしている必要があります。そのため、システムは再チェック条件を適用して、クラスタの更新の準備ができていることを確認し、クラスタのアップグレードが失敗した場合のロールバックをサポートします。
クラスタ マニフェストの特定の要素を変更することで、TKG クラスタのローリング アップデートを開始できます。ローリング クラスタ アップデートは、システムによって開始することもできます。たとえば、vSphere 名前空間 の更新を実行すると、システムは更新された構成を直ちにすべてのワークロード クラスタに伝達します。これらの更新によってクラスタ ノードのローリング アップデートをトリガすることができます。また、いずれかの構成要素に対する変更によってローリング アップデートを開始することもできます。たとえば、ディストリビューション バージョンに対応する VirtualMachineImage を名前変更または置換すると、システムが新しいイメージで実行されているすべてのノードの取得を試行するため、ローリング アップデートが開始されます。スーパーバイザー を更新した場合も、そこにデプロイされているワークロード クラスタのローリング アップデートがトリガされることがあります。たとえば、vmware-system-tkg-controller-manager が更新された場合、システムは新しい値をマニフェスト ジェネレータに導入し、コントローラはこれらの値をデプロイするローリング アップデートを開始します。
クラスタ ノードを置き換えるためのローリング アップデート プロセスは、Kubernetes 環境でのポッドのローリング アップデートと同様です。ワークロード クラスタのローリング アップデートを実行するコントローラは 2 つあります。アドオン コントローラとクラスタ コントローラです。これらの 2 つのコントローラでは、ローリング アップデートに、アドオンの更新、制御プレーンの更新、およびワーカー ノードの更新の 3 つの主要なステージがあります。これらのステージは順番に実行されますが、前の手順が十分に進行するまで次のステップの開始を防ぐ事前チェックが実行されます。不要と判断された場合、ステップはスキップされることがあります。たとえば、更新がワーカー ノードのみに影響する場合、アドオンや制御プレーンの更新は必要なくなります。
更新プロセスでは、システムは新しいクラスタ ノードを追加し、ノードがターゲットの Kubernetes バージョンでオンラインになるまで待機します。その後、古いノードを削除対象としてマークし、次のノードに移動して、プロセスを繰り返します。すべてのポッドが削除されるまで、古いノードは削除されません。たとえば、ノードの完全なドレーンを妨げる PodDisruptionBudgets でポッドが定義されている場合、ノードは遮断されますが、それらのポッドが消去できるようになるまで削除されません。システムは、最初にすべての制御プレーン ノード、次にワーカー ノードをアップグレードします。更新中は、クラスタのステータスが「更新中」に変わります。ローリング アップデート プロセスが完了すると、クラスタのステータスが「実行中」に変わります。
レプリケーション コントローラによって管理されていないクラスタで実行されているポッドは、クラスタの更新中にワーカー ノードのドレインの一環として、Kubernetes バージョンのアップグレードで削除されます。クラスタの更新が手動でトリガされた場合や、vSphere 名前空間または スーパーバイザー の更新によって自動実行された場合がこれに該当します。レプリケーション コントローラによって管理されていないポッドには、Deployment または ReplicaSet 仕様の一部として作成されていないポッドなどがあります。詳細については、Kubernetes ドキュメントのPod Lifecycle: Pod lifetimeを参照してください。
ユーザーが開始するローリング アップデート
システムが開始するローリング アップデート
- kubeadmcontrolplanetemplate/kubeadmcontrolplane
- kubeadmconfigtemplate/kubeadmconfig
- vspheremachinetemplate/vspheremachine（vSphere 8.x の場合）
- wcpmachinetemplate/wcpmachine（vSphere 7.x の場合）
vSphere IaaS control plane では、スーパーバイザー で実行されている TKG コントローラによってこれらのオブジェクトが生成され、システム コードとの同期が維持されます。これにより、コントローラが新しいコードに更新された場合、上記のオブジェクトのいずれかを変更すると、既存の TKG クラスタがローリング アップデートされます。つまり、スーパーバイザー に影響する変更をシステム コードに加えると、TKG クラスタがローリング アップデートされます。
| アップグレードのシナリオ | 説明 |
|---|---|
| 任意の vCenter Server 7.x リリースから任意の vCenter Server リリースへのアップグレード | すべての Tanzu Kubernetes クラスタのローリング アップデートがトリガされる場合があります。 ローリング アップデートは、vCenter Server のアップグレードに続くスーパーバイザーの最初のアップグレードによってトリガされます。通常、ローリング アップデートは、同じ vCenter Server でのスーパーバイザーのアップグレードによってトリガされることはありません。 詳細については、リリース ノートを参照してください。 |
| 任意の vCenter Server リリースから任意の vCenter Server 8.x リリースへのアップグレード | 次のコード変更を反映させる必要があるため、すべての TKG クラスタのローリング アップデートがトリガされます。
|
| vCenter Server 8.0 GA リリース (8.0.0) から vCenter Server 8.0.0b または 8.0.0c リリースへのアップグレード | 次のいずれかのケースが当てはまる場合は、指定した TKG クラスタのローリング アップデートがトリガされます。
|
| vSphere 8.0.0b リリースから vSphere 8.0.0c リリースへのアップグレード | ワークロード クラスタの自動ロールアウトなし |
| vSphere 8.0.0c リリースから vSphere 8.0 Update 1 リリース (8.0.1) へのアップグレード | ワークロード クラスタの自動ロールアウトなし |
| 任意の vSphere 8.x バージョンから 8.0 U2 リリース (8.0.2) へのアップグレード | 以下の変更を行う必要があるため、すべての TKC に対するローリング アップグレードが実行されます。
|
| 8.0 U2 (8.0.2) 未満の任意の vSphere 8.x バージョンから 8.0 U2c リリースへのアップグレード | 以下の変更を行う必要があるため、すべての TKC に対するローリング アップグレードが実行されます。
|
たとえば、システム定義の OVA 名を自動的に使用するサブスクライブ済みコンテンツ ライブラリを使用しているシナリオについて考えます。ここでは、ローカル コンテンツ ライブラリに切り替え、同じ OVA をポピュレートしてそれぞれ異なる名前を指定します。これにより、すべての TKG クラスタのローリング アップデートがトリガされます。置換後のコンテンツ ライブラリには同じ OVA がありますが、ユーザー定義の異なる名前を持つためです。
複数のノード プールを持つクラスタのローリング アップデートに関する考慮事項
- ワーカー ノード プール
-
ワーカー ノード プールは、vSphere 7 U3 でリリースされた TKGS v1alpha2 API で導入されました。クラスタ API MachineDeployments は、ワーカー ノード プールの基盤となる Kubernetes プリミティブです。
ClusterClass は、vSphere 8 リリースの TKGS で導入されました。v1alpha3 API と v1beta1 API の両方が ClusterClass に基づいています（v1alpha3 は ClusterClass 上の抽象化レイヤーです）。
- ローリング アップデート中に複数のノード プールを更新する方法
-
複数のノード プールを使用してプロビジョニングされた TKGS ワークロード クラスタを更新する場合は、使用されている vSphere のバージョンによってローリング アップデート モデルが異なります。
vSphere TKGS API アップグレードの動作 vSphere 7 TKGS v1alpha2 API 同じクラスタ内の複数のノード プールが同時に更新されます vSphere 8 TKGS v1alpha3 API および v1beta1 API 同じクラスタ内の複数のノード プールが論理的な順序に従って（順番に）更新されます
- ベスト プラクティスに関する考慮事項
-
同一の複数のノード プールを使用して vSphere 8 TKGS クラスタをプロビジョニングしても、サイジングの観点からは意味がありません。ノード プールは、サイズ、仮想マシン クラス、TKr バージョンなどが異なる場合に使用する必要があります。複数の同一のノード プールを使用してクラスタを迅速にアップグレードしても効果がないため、この処理は行わないでください。
Pod Disruption Budget は、アップグレードが実行中のアプリケーションに干渉しないようにするための適切な方法です。これに対処する最善の方法は、ワークロードに PodDisruptionBudgets を設定することです（https://kubernetes.io/docs/tasks/run-application/configure-pdb/ を参照）。クラスタ API はこれらの設定を考慮し、しきい値を超えるとマシンを終了しません。
