#概览

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

可以通过 Web Console、ACP CLI 提交升级请求，也可以直接编辑 ClusterVersionShadow。Web Console 提供两种集群管理界面：一种是平台内置界面，另一种是由 Alauda Container Platform Fleet Essentials 集群插件提供的新界面。这两种界面均在 global 集群和业务集群页面中并列介绍。

将平台升级到新的 ACP Distribution Version 时，应先升级 global 集群，再升级业务集群：

1. 按照经过验证的 global 集群操作步骤，将 global 层升级到目标 Distribution Version，其中包括准备制品和执行升级前检查。
2. global 层达到目标 Distribution Version 后，从受支持的业务集群升级入口升级业务集群，并监控集群状态，直至每个目标集群都达到相同的 Distribution Version。

业务集群只能升级到 global 层已达到的 Distribution Version。在启用了 global 灾难恢复 (DR) 的环境中，这意味着必须先将备用和主 global 集群都升级到目标 Distribution Version，然后才能将业务集群升级到该 Distribution Version。升级 global 层之前，请在 Kubernetes 支持矩阵中确认每个业务集群的版本都在目标 Distribution Version 的兼容版本范围内。此项前提条件与升级顺序规则相互独立。

#按节点操作系统执行升级

根据节点操作系统的不同，每个集群的升级分为一个或两个步骤：

1. 升级 Distribution Version适用于两种节点操作系统。CVO 会将 Core 和已安装的 Aligned 插件升级到目标 Distribution Version。在运行非 Alauda OS 的集群上，此步骤还会在现有节点上原地升级 Kubernetes。
2. 在 Alauda OS 上升级 Kubernetes仅适用于 Alauda OS 集群。Distribution Version 升级完成后，通过 Cluster API 滚动更新替换节点，从而部署 Kubernetes 和 Alauda OS 镜像。节点不会原地升级。

#Distribution Version 与 Kubernetes 版本

在运行非 Alauda OS 的集群上，CVO 会在升级 Distribution Version 时一并升级 Kubernetes。在 Alauda OS 集群上，ACP 次要版本系列在其补丁生命周期内可能提供多个经过验证的 Kubernetes 目标版本。有关 Kubernetes 升级可用的特定补丁版本对应的 Kubernetes 和组件值，请参阅 OS 支持矩阵。

#升级工作流

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

1. 升级前准备：确认受支持的升级路径、集群就绪状态以及完整的目标版本制品集。
2. 升级 global 集群：升级 Distribution Version；如果启用了 global DR，则改为执行在 DR 环境中升级。如果 global 集群运行 Alauda OS，请继续执行在 Alauda OS 上升级 Kubernetes。在 DR 环境中，请在两个 global 集群上执行此操作。
3. 在 global 层达到目标 Distribution Version 后升级业务集群：升级 Distribution Version。对于运行 Alauda OS 的业务集群，请继续执行在 Alauda OS 上升级 Kubernetes。
4. 升级验证：确认 Distribution Version、Kubernetes、Core、Aligned 插件、Pod、制品、CVO 历史记录和 Web UI。
5. 升级故障排除：仅当升级前检查或执行报告阻塞或停滞时使用。

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

#关键概念

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

#升级范围和顺序

完整的 ACP 升级分阶段进行。每个集群在一个维护窗口内完成升级，但平台会逐个集群推进，先升级 global 集群，再升级业务集群。

单个集群的升级窗口包含四类工作：

以下规则决定各部分的推进时机：

• 平台要求集群的 Kubernetes 版本与其 Core 和 Aligned 版本一起升级；新 Core 版本与旧 Kubernetes 次要版本混用未经验证。
• 请求升级前，请确保该集群上已安装的每个 Aligned 插件都有目标版本软件包可用。对于来自 ACP Upgrade to v4.5 的软件包，请使用同步升级制品中的 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 Console 请求升级、使用 ACP CLI，或直接更新 ClusterVersionShadow.spec.desiredUpdate。
• 业务集群：目标 Distribution Version 对业务集群可用后，使用 Web Console 或 ACP CLI。

#相关文档

• 升级前准备
• 升级 global 集群的 Distribution Version
• 在 Alauda OS 上升级 global 集群的 Kubernetes
• 在 DR 环境中升级 global 集群
• 升级业务集群的 Distribution Version
• 在 Alauda OS 上升级业务集群的 Kubernetes
• 更改 Alauda OS 节点的计算机规格
• 升级验证
• 升级故障排除
• global 集群灾难恢复