概览
ACP 4.3 使用基于 Cluster Version Operator (CVO) 的工作流进行集群升级。
在 Web Console 中，升级请求现在遵循两步流程：先审查 RPCH 项，然后在单独的确认步骤中提交升级请求。
当将平台迁移到新的 ACP Distribution Version 时，升级通常分为两个阶段进行：
- 通过遵循经过验证的 global 集群操作步骤，将 global 层升级到目标 Distribution Version，其中包括 artifact 准备和预检。
- 当 global 层达到目标 Distribution Version 后，从受支持的业务集群入口升级业务集群，并持续观察集群状态，直到每个目标集群都达到相同的 Distribution Version。
业务集群只能升级到 global 层已经达到的 Distribution Version。在具有 global disaster recovery (DR) 的环境中，这意味着在业务集群升级到该 Distribution Version 之前，备用和主 global 集群都必须先达到目标 Distribution Version。此顺序规则不会替代 Compatible Versions 前置条件：在 global 层升级到 ACP 4.3 之前，业务集群必须始终保持在与 ACP 4.3 兼容的 Kubernetes 版本范围内。
关键概念
- ClusterVersionShadow (
cvsh)：用于跟踪当前版本、目标版本、预检结果、执行阶段和历史记录的升级资源。 - Distribution Version：集群当前达到的 ACP 版本。业务集群只能升级到 global 层已经达到的 Distribution Version。
- Preflight：在升级开始应用目标版本之前运行的校验检查。对于业务集群，在提交升级请求后，请从升级状态输出中查看 preflight 结果。
- 可用升级目标：当前为集群提供的升级版本。在 Web Console 中，当前升级流程的目标版本由平台决定。
- upgrade.sh：用于 global 集群升级的准备脚本。artifact 同步和 preflight 检查可在维护窗口之前执行；cluster version operator 会在窗口内、升级请求发出之前部署。
- global DR 环境：同时包含主 global 集群和备用 global 集群的环境。
- 主 global 集群：平台访问域当前解析到的 global 集群。
- 备用 global 集群：DR 对中的另一个 global 集群。发生故障切换后，两个集群的角色会互换。
升级范围与顺序
完整的 ACP 升级是分阶段进行的。每个集群在一个维护窗口内完成升级，但平台是按集群逐个推进的，先 global，后业务集群。
单个集群的升级窗口包含四类工作：
以下规则决定各部分何时迁移：
- 平台要求集群的 Kubernetes 版本必须与其 Core 和 Aligned 版本一起升级；将新的 Core 版本与旧的 Kubernetes 次要版本混合使用未经过验证。
- 在请求升级之前，请为该集群上已经安装的每个 Aligned 插件发布目标版本包。任何已安装的 Aligned 插件缺少包都会阻塞 CVO 升级。对于该集群上未安装的 Aligned 插件，不需要发布包，也不会阻止升级。
- 集群插件是全局资源。将集群插件推送到 global 层后，它就可以在平台中的每个集群上安装和升级；无需为每个业务集群再次推送同一个集群插件。
- operator 作用域限定于每个集群。建议将 operator 推送到 global 层，但这本身还不够；在业务升级之前，必须在每个业务集群上都能获取到相同的 operator。如果您在 global 窗口中忘记推送某个 operator，可以在业务升级前再次推送，作为兜底方案。
- 只有当业务集群超出了目标 ACP 版本的 Kubernetes 支持矩阵 时，才需要进行业务集群升级。保持在受支持范围内的业务集群，在 global 层迁移后可以继续使用现有的 Kubernetes 版本；平台会继续管理它们。
CVO 管理范围
Cluster Version Operator (CVO) 决定它端到端驱动哪些类型的升级：
在真实生产维护窗口中，客户通常会将 Core、Aligned 以及正在使用的 Agnostic 插件一起迁移。下面的升级页面记录了该路径：在升级前准备期间准备所有所需的 artifact，通过 CVO 驱动 Core 和 Aligned 的升级，然后从 Marketplace 完成正在使用的 Agnostic 插件。
传统环境与 Immutable Infrastructure 上的 Kube-OVN
在 传统操作系统 集群上（本页的适用范围），Kube-OVN 是 Core 的一部分，并由 CVO 与其他 Core 一起自动升级——operator 不会为每个集群修补 Kube-OVN 版本注解，也不会手动处理 Kube-OVN AppRelease。
在 Immutable Infrastructure 集群上（DCS、vSphere、HCS），Kube-OVN 由 IaaS 提供商通过业务 Cluster 资源上的 cpaas.io/kube-ovn-version 注解单独驱动——请参见 在 Immutable Infrastructure 上升级集群。该路径不适用于传统 OS 集群。
升级入口
- global 集群：遵循经过验证的、基于
upgrade.sh的操作步骤。在准备阶段完成后，可以通过 Web Console 的两步 RPCH 审查流程、ACP CLI，或直接更新ClusterVersionShadow.spec.desiredUpdate来请求升级。 - 业务集群：在目标 Distribution Version 对业务集群可用后，使用 Web Console 的两步 RPCH 审查流程或 ACP CLI。
升级后安全加固
在 global 集群和所有业务集群都达到 ACP 4.3 后，请按照 禁用 PKCE Plain Method 完成 PKCE 安全加固。
在 global 集群达到 ACP 4.3 后，请按照 升级 global 集群 完成所需的 L5 插件兼容性升级。