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 部署中的 pod 滚动更新。有两个不同的控制器负责执行工作负载集群的滚动更新：加载项控制器和集群控制器。在这两个控制器中，滚动更新有三个关键阶段：更新加载项、更新控制平面以及更新工作节点。这些阶段按顺序进行，并执行预检查以防止某一步骤在前一步骤充分完成之前开始。如果确定不需要执行这些步骤，则可以跳过这些步骤。例如，更新可能仅影响工作节点，因此不需要任何加载项或控制平面更新。
在更新过程中，系统会添加一个新的集群节点，并等待该节点与目标 Kubernetes 版本一起上线。然后，系统将旧节点标记为删除，移至下一个节点，并重复此过程。移除所有 pod 后，才会删除旧节点。例如，如果 pod 定义为 PodDisruptionBudgets 以阻止某节点完全引流，则该节点将隔离，直到可以逐出这些 pod 后才会移除。系统首先升级所有控制平面节点，然后再升级工作节点。在更新过程中，集群状态将更改为“正在更新”。滚动更新过程完成后，集群状态将更改为“正在运行”。
在 Kubernetes 版本升级过程中，在不受复制控制器监管的集群上运行的 Pod 将在集群更新期间作为工作节点引流过程的一部分删除。如果手动触发集群更新或由 vSphere 命名空间或 主管 更新自动触发，则会出现此情况。不受复制控制器监管的 Pod 包括不作为 Deployment 或 ReplicaSet 规范的一部分创建的 Pod。有关详细信息，请参考 Kubernetes 文档中的 Pod 生命周期：Pod 生命周期。
用户启动的滚动更新
系统启动的滚动更新
- 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 是在 TKGS vSphere 8 版本中引入的。v1alpha3 和 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 中断预算是确保升级不会干扰正在运行的应用程序的正确方法。处理此问题的最佳方法是在工作负载上设置 PodDisruptionBudgets（请参见 https://kubernetes.io/docs/tasks/run-application/configure-pdb/）。集群 API 遵守这些限制，如果超出阈值，将不会终止计算机。
