概览
ACP 4.3 使用基于 Cluster Version Operator (CVO) 的工作流进行集群升级。
在 Web Console 中，升级请求现在采用两步流程：先审查 RPCH 项，然后在单独的确认步骤中提交升级请求。
当将平台迁移到新的 ACP Distribution Version 时，升级通常分两个阶段进行：
- 按照已验证的 global-cluster 操作步骤将 global 层升级到目标 Distribution Version，包括制品准备和预检检查。
- 当 global 层达到目标 Distribution Version 后，从受支持的业务集群入口点升级业务集群，并观察集群状态，直到每个目标集群都达到相同的 Distribution Version。
业务集群只能升级到 global 层已经达到的 Distribution Version。在具有 global disaster recovery (DR) 的环境中，这意味着在业务集群升级到该 Distribution Version 之前，备用 global 集群和主 global 集群都必须先达到目标 Distribution Version。这个顺序规则不会取代 Compatible Versions 前提：在 global 层升级到 ACP 4.3 之前，业务集群必须始终保持在 ACP 4.3 兼容的 Kubernetes 版本范围内。
关键概念
- ClusterVersionShadow (
cvsh)：用于跟踪当前版本、期望版本、预检结果、执行阶段和历史记录的升级资源。 - Distribution Version：集群当前达到的 ACP 版本。业务集群只能升级到 global 层已经达到的 Distribution Version。
- Preflight：在升级开始应用目标版本之前运行的验证检查。对于业务集群，请在提交升级请求后，从升级状态输出中查看预检结果。
- 可用升级目标：当前为集群提供的升级版本。在 Web Console 中，当前升级流程的目标版本由平台决定。
- upgrade.sh：用于 global 集群升级的准备脚本。制品同步和预检检查可以在维护窗口之前执行；cluster version operator 会在窗口内、升级请求提交之前部署。
- Global DR 环境：同时包含主 global 集群和备用 global 集群的环境。
- 主 global 集群：平台访问域当前解析到的 global 集群。
- 备用 global 集群：DR 对中的另一个 global 集群。发生故障切换后，两个集群的角色会互换。
升级范围和顺序
完整的 ACP 升级是分阶段进行的。每个集群都在单个维护窗口内完成升级，但平台是按集群逐个迁移的，先 global，后业务集群。
单个集群的升级窗口包含四类工作：
每个部分何时迁移由以下规则约束：
- 平台要求集群的 Kubernetes 版本必须与其 Core 和 Aligned 版本一起升级；将新的 Core 发布与旧的 Kubernetes 次版本混用未经过验证。
- cluster plugin 是全局资源。将 cluster plugin 推送到 global 层后，它就可以在平台中的每个集群上安装和升级；无需针对每个业务集群再次推送同一个 cluster plugin。
- operator 按集群范围进行管理。建议将 operator 推送到 global 层，但这本身还不够；在业务升级之前，每个业务集群上都必须提供相同的 operator。如果你在 global 窗口期间忘记推送某个 operator，可以在业务升级之前再次推送，作为备用方案。
- 只有当业务集群超出目标 ACP 版本的 Kubernetes Support Matrix 时，才需要进行业务集群升级。对于仍处于受支持范围内的业务集群，在 global 层迁移后可以保留现有的 Kubernetes 版本；平台会继续管理它们。
CVO 管理范围
Cluster Version Operator (CVO) 决定它端到端驱动哪些类型的升级：
在真实生产维护窗口中，客户通常会将 Core、Aligned，以及正在使用的 Agnostic plugins 一起迁移。下面的升级页面记录了这一路径：在预升级期间准备所有必需的制品，通过 CVO 驱动 Core 和 Aligned，并在 Marketplace 中完成正在使用的 Agnostic plugins。
传统环境与 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的操作步骤执行。准备阶段完成后，可通过两步 RPCH 审查流程在 Web Console 中发起升级，使用 ACP CLI，或者直接更新ClusterVersionShadow.spec.desiredUpdate。 - 业务集群：在目标 Distribution Version 对业务集群可用后，使用 Web Console 的两步 RPCH 审查流程，或使用 ACP CLI。
升级后安全加固
在 global 集群和所有业务集群都达到 ACP 4.3 后，请按照 禁用 PKCE Plain 方法 完成 PKCE 安全加固。
在 global 集群达到 ACP 4.3 后，请在 升级 global 集群 中完成所需的 L5 插件兼容性升级。