概览
ACP 4.3 使用基于 Cluster Version Operator (CVO) 的工作流进行集群升级。
在 Web Console 中，升级请求现在遵循两步流程：先审查 RPCH 项，随后在单独的确认步骤中提交升级请求。
当将平台迁移到新的 ACP Distribution Version 时，升级通常分两个阶段进行：
- 按照经过验证的 global 集群操作步骤，将 global 层升级到目标 Distribution Version，包括 artifact 准备和 preflight 检查。
- 在 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)：用于跟踪当前版本、目标版本、preflight 结果、执行阶段和历史记录的升级资源。 - Distribution Version：集群当前达到的 ACP 版本。业务集群只能升级到 global 层已经达到的 Distribution Version。
- Preflight：在升级开始应用目标版本之前运行的验证检查。对于业务集群，请在提交升级请求后，从升级状态输出中查看 preflight 结果。
- Available upgrade targets：当前为集群提供的升级版本。在 Web Console 中，当前升级流程的目标版本由平台确定。
- upgrade.sh：用于上传 artifact 并在升级继续之前部署或更新 cluster version operator 的准备脚本。
- Global DR environment：同时包含主 global 集群和备用 global 集群的环境。
- Primary global cluster：平台访问域当前解析到的 global 集群。
- Standby global cluster：DR 对中的另一个 global 集群。发生故障切换后，这两个集群的角色会互换。
升级入口点
- Global clusters：遵循经过验证的
upgrade.sh基础操作步骤。在准备阶段完成后，可通过 Web Console 中的两步 RPCH 审核流程发起升级、使用 ACP CLI，或直接更新ClusterVersionShadow.spec.desiredUpdate。 - Workload clusters：在目标 Distribution Version 对业务集群可用后，可通过 Web Console 中的两步 RPCH 审核流程或使用 ACP CLI。
升级后安全加固
在 global 集群和所有业务集群都达到 ACP 4.3 后，请按照 Disabling the PKCE Plain Method 完成 PKCE 安全加固。
在 global 集群达到 ACP 4.3 后，请在 Upgrade the global cluster 中完成所需的 L5 plugin 兼容性升级。