#概览

从 ACP 4.3 开始，集群升级采用基于 Cluster Version Operator (CVO) 的工作流。

升级请求可通过 Web 控制台、ACP CLI 提交，或直接编辑 ClusterVersionShadow。Web 控制台提供两种集群管理界面：平台自带的内置界面，以及由 Alauda Container Platform Fleet Essentials 集群插件提供的新界面。两者均在 global 集群和业务集群页面中并列说明。

将平台迁移到新的 ACP 发行版本时，升级通常分两个阶段进行：

1. 按照经验证的 global 集群操作步骤，将 global 层升级到目标发行版本，包括制品准备和预检。
2. 在 global 层达到目标发行版本后，从受支持的业务集群入口升级业务集群，并观察集群状态，直至每个目标集群达到相同的发行版本。

业务集群只能升级到 global 层已经达到的发行版本。在启用 global 容灾（DR） 的环境中，这意味着备用和主 global 集群都必须先达到目标发行版本，然后才能将业务集群升级到该发行版本。在升级 global 层之前，请确认每个业务集群均处于目标发行版本在 Kubernetes 支持矩阵 中的 兼容版本 范围内。此前提条件独立于顺序规则。

#升级工作流

请按以下顺序阅读各页面：

1. 升级前准备：确认受支持的升级路径、集群就绪状态，并备齐目标版本的完整软件包集合。
2. 升级 global 集群，或在启用 global DR 时 在 DR 环境中升级 Global 集群。
3. 在 global 层达到目标发行版本后，升级业务集群。
4. 升级验证：验收发行版本、Kubernetes、Core、Aligned 插件、Pods、制品、CVO 历史记录和 Web UI。
5. 升级故障排查：仅在预检或执行报告阻塞或停滞时使用。

规划维护时间线，确保准备工作在变更窗口之前完成：

#关键概念

• ClusterVersionShadow (cvsh)：用于跟踪当前版本、期望版本、预检结果、执行阶段和历史记录的升级资源。
• 发行版本（Distribution Version）：集群当前已达到的 ACP 版本。业务集群只能升级到 global 层已经达到的发行版本。
• 预检（Preflight）：在升级开始应用目标版本之前运行的验证检查。对于业务集群，在提交升级请求后，从升级状态输出中查看预检结果。
• 可用升级目标：当前为集群提供的升级版本。在 Web 控制台中，当前升级流程的目标版本由平台确定。
• upgrade.sh：用于 global 集群升级的准备脚本。使用平台内置 Registry 时，它会同步 Core 制品以及暂存在 plugins/ 中的软件包。使用外部 Registry 时，将跳过同步，目标 payload 需单独上传。该脚本还会在适当阶段运行预检并部署 CVO。
• Global DR 环境：同时包含主 global 集群和备用 global 集群的环境。
• 主 global 集群：平台访问域名当前解析到的 global 集群。
• 备用 global 集群：DR 配对中的另一个 global 集群。故障转移后，两个集群的角色会互换。

#升级范围与顺序

完整的 ACP 升级是分阶段进行的。每个集群在单个维护窗口中完成升级，但平台按集群逐个迁移，先升级 global，再升级业务集群。

单个集群升级窗口涵盖四类工作：

若干规则决定各部分的迁移时机：

• 平台要求集群的 Kubernetes 版本必须与其 Core 和 Aligned 版本一同升级；将新的 Core 发行版与旧的 Kubernetes 次版本混用未经验证。
• 在请求升级之前，请为该集群上已安装的每个 Aligned 插件提供目标版本的软件包。对于来自 ACP Upgrade to v4.4 的软件包，使用 同步升级制品 中的 plugins/ 发布路径；对于其他 Aligned 软件包，使用 violet。已安装的 Aligned 插件缺少软件包会导致 CVO 升级停滞。未安装在集群上的 Aligned 插件的软件包不会导致这些插件被安装。
• 集群插件是全局资源。通过 global 层制品发布或 violet 工作流提供的软件包可供平台中的每个集群使用；无需按业务集群再次发布相同的集群插件。
• Operator 的作用域限定在每个集群。将 operator 推送到 global 层是推荐做法，但仅此还不够；在业务集群升级之前，相同的 operator 必须在每个业务集群上可用。如果在 global 窗口期间忘记推送某个 operator，可以在业务集群升级前再次推送作为补救。
• 仅当业务集群超出目标 ACP 发行版的 Kubernetes 支持矩阵 时，才需要升级业务集群。仍处于受支持范围内的业务集群可以在 global 层迁移后保留其现有 Kubernetes 版本；平台将继续管理它们。

#CVO 管理范围

Cluster Version Operator (CVO) 决定由它端到端驱动哪些类型的升级：

在真实生产维护窗口中，客户通常会同时迁移 Core、Aligned 以及正在使用的 Agnostic 插件。以下升级页面记录了该路径：在升级前准备所有所需制品，通过 CVO 驱动 Core 和 Aligned，并从 Marketplace 完成正在使用的 Agnostic 插件。

#升级入口

• Global 集群：遵循经验证的基于 upgrade.sh 的操作步骤。准备阶段完成后，从 Web 控制台请求升级、使用 ACP CLI，或直接更新 ClusterVersionShadow.spec.desiredUpdate。
• 业务集群：在目标发行版本对业务集群可用后，使用 Web 控制台或 ACP CLI。

#相关文档

• 升级前准备
• 升级 global 集群
• 在 DR 环境中升级 global 集群
• 升级业务集群
• 升级验证
• 升级故障排查
• Global 集群容灾