Alauda Container Platform
  • 简体中文

    • 概览

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

    在 Web Console 中，升级请求现在采用两步流程：先审查 RPCH 项目，然后在单独的确认步骤中提交升级请求。

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

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

    业务集群只能升级到 global 层已经达到的 Distribution Version。在启用了 global disaster recovery (DR) 的环境中，这意味着在业务集群升级到该 Distribution Version 之前，备用和主 global 集群都必须先达到目标 Distribution Version。在升级 global 层之前，请确认每个业务集群都位于 Kubernetes 支持矩阵中该目标 Distribution Version 的 Compatible Versions 范围内。此先决条件与顺序规则是分开的。

    目录

    升级工作流关键概念升级范围和顺序CVO 管理范围升级入口相关文档

    升级工作流

    请按以下顺序阅读页面：

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

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

    阶段推荐时间状态变更
    下载并发布制品在维护窗口之前不会升级任何正在运行的组件。
    运行预检并解决阻塞在窗口前 1–2 周只读检查；修复操作可单独更改环境。
    升级 global 层第一个维护窗口Core、Kubernetes 和已安装的 Aligned plugins 升级到目标版本。
    升级业务集群在 global 层之后每个选定的业务集群都在各自受控的窗口内升级。
    验证并完成后续工作在关闭每个窗口之前确认接受结果并完成所需的升级后操作。

    关键概念

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

    升级范围和顺序

    完整的 ACP 升级采用分阶段方式进行。每个集群都在单个维护窗口内升级，但平台是按集群逐个推进的，先 global，后业务集群。

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

    工作项必需？升级方式如果运行 immutable OS
    Core（平台本身）必需由通过同步升级制品准备的制品驱动的 CVO控制流相同；Kubernetes 步骤单独处理，见下文
    Aligned plugins（与匹配的 ACP 版本一起发布的集群插件和 operator）对每个已安装插件均为必需对于通过 ACP Upgrade to v4.4 提供的 Aligned 应用，请手动将其包复制到 plugins/ 中，并通过同步升级制品发布。其他已安装的 Aligned 包请使用 violet 发布。随后，CVO 会在集群升级过程中升级每个已安装的 Aligned plugin。相同
    Kubernetes在同一窗口内必需在传统 OS 集群上，CVO 会在同一次集群升级中就地升级现有节点上的 Kubernetes；不会替换节点。Kubernetes 通过 Cluster API 滚动更新，使用新的基于 Alauda OS 的镜像替换节点来进行部署，而不是就地升级。相关操作步骤位于不可变基础设施文档中；请参见 在 Huawei DCS 上升级集群、在 VMware vSphere 上升级集群，或 在 Huawei Cloud Stack 上升级集群
    Agnostic plugins（独立发布的集群插件和 operator）可选，按插件分别处理在集群达到目标 Distribution Version 后，从 Marketplace > Cluster Plugins 或通过 operator 自己的工作流升级每个 cluster plugin 或 operator相同

    每个部分何时迁移受以下规则约束：

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

    CVO 管理范围

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

    生命周期类型是否由 CVO 驱动？说明
    Core是，CVO 是唯一受支持的路径Core 升级需要通过 global 集群同步工作流准备的制品；CVO 会消费这些制品。
    Aligned plugins默认是cluster plugin 或 operator 工作流也可以脱离主流程升级单个 Aligned plugin，例如在不将集群迁移到新的 Distribution Version 的情况下应用关键安全修复。
    Agnostic plugins否CVO 不管理这些内容。请在集群达到目标 Distribution Version 后，从 Marketplace > Cluster Plugins 升级每个 cluster plugin，并通过各自的工作流升级每个 operator。

    在真实生产维护窗口中，客户通常会将 Core、Aligned 以及正在使用的 Agnostic plugins 一起迁移。下面的升级页面记录了这一路径：在升级前准备阶段准备所有必需的制品，通过 CVO 推进 Core 和 Aligned，并从 Marketplace 完成正在使用的 Agnostic plugins。

    INFO

    传统环境与 Immutable Infrastructure 上的 Kube-OVN

    在传统操作系统集群上（本页面的范围），Kube-OVN 是 Core 的一部分，会随着其他 Core 内容一起由 CVO 自动升级——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。

    相关文档