Alauda Container Platform
  • 简体中文

    • 概览

    ACP 4.3 使用基于 Cluster Version Operator（CVO）的工作流进行集群升级。

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

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

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

    workload 集群只能升级到 global 层已经达到的 Distribution Version。在具有 global disaster recovery (DR) 的环境中，这意味着在将 workload 集群升级到该 Distribution Version 之前，备用 global 集群和主 global 集群都必须先达到目标 Distribution Version。此顺序规则不会取代 Compatible Versions 前提：在 global 层升级到 ACP 4.3 之前，workload 集群必须保持在 ACP 4.3 兼容的 Kubernetes 版本范围内。

    目录

    关键概念升级范围与顺序CVO 管理范围升级入口升级后安全加固相关文档

    关键概念

    • ClusterVersionShadow (cvsh)：用于跟踪当前版本、期望版本、预检结果、执行阶段和历史记录的升级资源。
    • Distribution Version：集群当前达到的 ACP 版本。workload 集群只能升级到 global 层已经达到的 Distribution Version。
    • Preflight：在升级开始应用目标版本之前运行的验证检查。对于 workload 集群，请在提交升级请求后，从升级状态输出中查看预检结果。
    • 可用升级目标：当前为集群提供的升级版本。在 Web Console 中，当前升级流程的目标版本由平台决定。
    • upgrade.sh：用于 global 集群升级的准备脚本。artifact 同步和预检可以在维护窗口之前运行；cluster version operator 会在窗口内、升级请求发出前部署。
    • Global DR 环境：同时具有主 global 集群和备用 global 集群的环境。
    • 主 global 集群：平台访问域当前解析到的 global 集群。
    • 备用 global 集群：DR 对中的另一个 global 集群。在故障切换后，这两个集群的角色会互换。

    升级范围与顺序

    完整的 ACP 升级是分阶段进行的。每个集群在单个维护窗口内完成升级，但平台是按集群逐个迁移的，先 global，后 workload 集群。

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

    工作项是否必需？升级方式如果运行不可变 OS
    Core（平台本身）必需CVO，由 upgrade.sh 准备的 artifact 驱动控制流相同；Kubernetes 步骤单独处理，见下文
    对齐插件（与匹配的 ACP 版本一同发布的集群插件和 operator）同一窗口内必需默认由 CVO 升级；在需要离线修复时，也可以通过集群插件或 operator 工作流单独升级相同
    Kubernetes同一窗口内必需通过 Cluster API 滚动更新，使用新的基于 Alauda OS 的 DCSMachineTemplate（或等效的不可变模板）替换 VMKubernetes 升级操作步骤位于不可变基础设施文档中；请参见 在 Huawei DCS 上升级集群、在 VMware vSphere 上升级集群，或 在 Huawei Cloud Stack 上升级集群
    无关插件（独立发布的集群插件和 operator）可选，按插件单独处理在集群达到目标 Distribution Version 后，从 Marketplace > Cluster Plugins 或 operator 自身工作流升级每个集群插件或 operator相同

    以下规则决定了各部分的升级时机：

    • 平台要求集群的 Kubernetes 版本必须与 Core 和对齐版本一起升级；将新的 Core 版本与旧的 Kubernetes 次版本混合使用不会经过验证。
    • 集群插件是全局资源。将集群插件推送到 global 层后，平台中的每个集群都可以安装和升级该插件；你不需要针对每个 workload 集群重复推送同一个集群插件。
    • Operator 以单个集群为作用域。建议将 operator 推送到 global 层，但这本身还不够；在 workload 升级之前，同一个 operator 必须已在每个 workload 集群上可用。如果你在 global 窗口期间忘记推送某个 operator，可以在 workload 升级前再次推送，作为兜底方案。
    • 只有当 workload 集群超出目标 ACP 发布版本的 Kubernetes Support Matrix 时，才需要进行 workload 集群升级。仍处于受支持范围内的 workload 集群在 global 层迁移后可以保留现有的 Kubernetes 版本；平台会继续管理它们。

    CVO 管理范围

    Cluster Version Operator（CVO）决定其端到端驱动哪些类型的升级：

    生命周期类型是否由 CVO 驱动？说明
    Core是，且 CVO 是唯一受支持的路径Core 升级需要 upgrade.sh 准备的 artifact；CVO 会消费这些 artifact。
    对齐插件默认是cluster plugin 或 operator 工作流也可以离线升级单个对齐插件——例如，在不将集群迁移到新的 Distribution Version 的情况下应用关键安全修复。
    无关插件否CVO 不管理这些插件。集群达到目标 Distribution Version 后，请从 Marketplace > Cluster Plugins 升级每个集群插件，并从各自的工作流升级每个 operator。

    在真实生产维护窗口中，客户通常会将 Core、对齐插件以及正在使用的无关插件一起迁移。下面的升级页面记录了这一路径：在预升级阶段准备所需的全部 artifact，通过 CVO 驱动 Core 和对齐插件，并从 Marketplace 完成正在使用的无关插件升级。

    INFO

    传统环境与不可变基础设施中的 Kube-OVN

    在传统操作系统集群（本页的范围）中，Kube-OVN 是 Core 的一部分，并且会随 Core 的其余部分一起由 CVO 自动升级——运维人员不会修补任何按集群维度的 Kube-OVN 版本注解，也不会手动处理 Kube-OVN AppRelease。

    在不可变基础设施集群（DCS、vSphere、HCS）中，Kube-OVN 由 IaaS 提供商通过 workload Cluster 资源上的 cpaas.io/kube-ovn-version 注解单独驱动——请参见 升级不可变基础设施上的集群。该路径不适用于传统 OS 集群。

    升级入口

    • global 集群：遵循经过验证的基于 upgrade.sh 的操作步骤。准备阶段完成后，可通过 Web Console 的两步式 RPCH 审核流程、ACP CLI，或直接更新 ClusterVersionShadow.spec.desiredUpdate 来发起升级。
    • workload 集群：在目标 Distribution Version 对 workload 集群可用后，使用 Web Console 的两步式 RPCH 审核流程或 ACP CLI。

    升级后安全加固

    在 global 集群和所有 workload 集群都达到 ACP 4.3 后，请按照 禁用 PKCE Plain 方法 完成 PKCE 安全加固。

    在 global 集群达到 ACP 4.3 后，请按照 升级 global 集群 完成所需的 L5 插件兼容性升级。

    相关文档