可以通过更新 Tanzu Kubernetes 版本 版本、更新虚拟机类以及更新存储类，对 主管 上的 TKG 2 集群启动滚动更新。在执行此操作之前，您应该验证集群兼容性，并了解滚动更新过程。

TKG 2 集群的滚动更新模型

TKG 控制器在 主管 上运行。更新 主管 时，如果有可用更新，则会自动更新 TKG 控制器。每个 TKG 控制器更新可以包括支持服务（如 CNI、CSI、CPI）的更新以及集群的配置更新。为了支持兼容性，系统将执行预检查并强制执行合规性。

TKG 使用滚动更新模型更新工作负载集群。滚动更新模型可确保将集群更新过程的停机时间降至最低。滚动更新包括升级 Kubernetes 软件版本和支持集群的基础架构和服务，例如虚拟机配置和资源、服务和命名空间以及自定义资源。为确保成功更新，您的配置必须满足多个兼容性要求，因此系统会实施复查条件以确保集群已准备好进行更新，并在集群升级失败时支持回滚。

您可以使用以下方法之一启动 TKG 2 的滚动更新：

系统也可以启动滚动集群更新。例如，执行 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）
主管升级时，核心集群 API (CAPI) 控制器将触发对 TKG 工作负载集群的更新部署，以将上述对象中的所需状态与正在运行的工作负载集群相匹配。

在 vSphere with Tanzu 中，在主管中运行的 TKG 控制器将生成这些对象，并使这些对象与系统代码保持同步。这意味着，当控制器更新到较新的代码时，对上述任何一个对象进行更改都会导致现有 TKG 集群执行滚动更新。总之，影响主管的系统代码更改会导致 TKG 集群进行滚动更新。

下表介绍了在哪些条件下，每当升级 主管时，都会导致工作负载集群自动进行滚动更新。
升级方案 描述
从任何 vSphere v7.x 版本升级到任何 vSphere v7.x 版本

将触发所有 TKG 集群进行滚动更新。
从任何 vSphere v7.x 版本升级到任何 vSphere v8.x 版本 将触发所有 TKG 集群进行滚动更新，因为需要传播以下代码更改：
  • 底层 CAPI 提供程序需要从 CAPW 移至 CAPV
  • 将集群从无类别 CAPI 集群迁移到类别 CAPI 集群
从 vSphere v8.0 GA 版本升级到 vSphere 8.0 MP1 或更高版本 如果出现以下任一情况，将触发指定的 TKG 集群进行滚动更新：
  • 使用具有非空 noProxy 列表的代理设置的任何 TKG 集群。
  • 所有 TKG 集群（如果在主管上启用了嵌入式 Habor 注册表服务）。
此外，更改托管 TKR 映像的内容库可能会触发 TKG 集群的滚动更新。通过订阅或手动添加新映像不会触发 TKG 集群进行滚动更新。但是，更改内容库并添加具有不同名称的映像将触发所有 TKG 集群进行滚动更新。

例如，假设您正在使用自动使用系统定义的 OVA 名称的已订阅内容库。然后，切换到本地内容库，并在其中填充相同的 OVA，但为其提供不同的名称。这将触发所有 TKG 集群进行滚动更新，因为替换内容库具有相同的 OVA，但具有用户定义的不同名称。

验证 TKG 2 集群兼容性以进行更新

升级工作负载集群之前，应检查其升级兼容性。如果集群与目标基础架构不兼容，请先升级集群，然后再继续执行系统升级。

可以使用以下命令列出 Tanzu Kubernetes 版本 并查看每个发行版的兼容性和可更新性。 
kubectl get tanzukubernetesreleases

COMPATIBLE 列指示 Tanzu Kubernetes 版本 是否与当前 主管 兼容。UPDATES AVAILABLE 列指示是否有 Kubernetes 升级可用，以及建议使用的下一个 Tanzu Kubernetes 版本。

使用 kubectl get tkc <tkgs-cluster-name> 和 kubectl get cluster <tkgs-cluster-name> 也可获取此信息。