Alauda Container Platform
  • 简体中文

    • 升级业务集群

    升级路径

    本页涵盖业务集群的传统操作系统路径。对于运行在 Immutable Infrastructure 上的业务集群（Alauda OS on Huawei DCS、VMware vSphere 或 Huawei Cloud Stack），Kubernetes 步骤位于 immutable infrastructure 文档中——请参见 升级 Immutable Infrastructure 上的集群。本页所述的 Core、Aligned 和 Agnostic 步骤仍适用于 immutable-OS 集群；不同之处仅在于 Kubernetes 的发布方式。

    Alauda Database Service for MySQL v4.3.0 中移除 MySQL-PXC

    从 Alauda Database Service for MySQL v4.3.0 开始，MySQL-PXC 已被移除。升级到 ACP v4.3.0 或更高版本后，现有 PXC 实例将不再由 MySQL operator 管理。升级前请参见 MySQL Operator Upgrade Guide 了解迁移说明。

    在 global 层已经到达目标 ACP Distribution Version 后，即可升级业务集群。如果 global 层已经处于该 Distribution Version，则无需再次升级。

    ACP 4.3 对业务集群使用与 global 集群相同的基于 CVO 的工作流：确认先决条件、运行 preflight 检查、请求升级并观察执行过程。该工作流还有两条额外规则：

    • 如果平台使用 global DR，则在任何业务集群升级到该 Distribution Version 之前，备用和主 global 集群都必须先达到目标 Distribution Version。
    • 目标版本通常只有在 global 层已经达到相同的 Distribution Version 后，才会对业务集群开放。

    业务集群升级的分阶段流程与 global 集群升级类似，但更短。业务集群没有自己的 cluster version operator——CVO 运行在 global 集群上，并集中驱动业务集群升级——因此业务集群本身没有 artifact synchronization 或 CVO deployment 步骤：

    阶段时间发生的内容
    1. Preflight维护窗口前 1–2 周确认先决条件并运行 upgrade.sh --cluster=<cluster> --preflight；在窗口开启前解决所有阻塞项。
    2. Upgrade维护窗口期间请求升级并观察执行过程，直到集群达到目标版本。

    目录

    工作流在所有业务集群都达到 ACP 4.3 之后相关文档

    工作流

    确认业务集群先决条件

    在请求升级之前，请确认：

    • 业务集群版本低于当前 global 集群版本。
    • global 层已经达到目标 ACP Distribution Version。
    • 在 global DR 环境中，备用和主 global 集群都已经达到该目标 Distribution Version。

    Operator push 回退

    升级 global 集群 中推荐的模式会在 global 升级窗口期间将 operator 包推送到每个 集群。如果已经按照该建议执行，那么业务集群已经拥有所需的所有 operator 包，可以跳过本节。

    集群插件不需要按业务集群单独推送。集群插件只要在 global 层推送过一次，就可以在平台中的每个集群上安装和升级。

    如果 global 窗口没有将 operator 包推送到此业务集群——例如，该集群在 global 窗口期间处于离线状态，或者是之后才添加的——请在提交升级请求之前，将每个正在使用的 operator 包推送到此业务集群：

    violet push <path/to/operator-package> \
  --target-catalog-source "platform" \
  --platform-address "https://<your-platform-domain>" \
  --platform-username "<platform_user>" \
  --platform-password "<platform_password>" \
  --clusters "<workload-cluster-name>"

    你只需要为业务集群上实际运行的 operator 推送 operator 包。仍保留在 global 侧的 Aligned 插件包会在业务集群升级期间由 CVO 自动获取。

    运行 preflight 检查

    **时间：**维护窗口前 1–2 周，以便在窗口开启前有时间解决任何阻塞项。

    以 preflight 模式对目标集群运行 upgrade.sh：

    bash upgrade.sh --cluster=<cluster> --preflight

    Preflight 为只读操作——它会验证升级就绪状态，但不会更改集群状态。

    Preflight 会返回两部分内容：

    输出目的
    Summary显示总体结果、当前版本、期望版本和期望镜像。
    Checks显示每个单独验证项的结果。

    如果 preflight 未通过，请不要提交升级请求，直到所有阻塞项都已解决。

    有关 preflight 阻塞处理模式，请参见 在需要时处理 preflight 阻塞。

    请求升级

    **时间：**在维护窗口期间，且 preflight 通过之后。

    通过以下任一入口请求升级。两个入口等效；请选择最符合你运营模式的方式。

    Web Console
    ACP CLI

    在 Web Console 中从业务集群启动升级。该请求遵循两步流程：

    • 在 Step 1 中，查看 RPCH 列表。
    • 单击 Acknowledge 继续到 Step 2。
    • 在 Step 2 中，查看 Current Version 和 Target Version。此阶段页面不会显示插件列表或警告面板。
    • 目标版本是当前 global 集群版本，无法在 Web Console 中手动选择。
    • 单击 Start Upgrade。
    • 提交请求后，页面会显示升级请求已提交，且该操作进入进行中状态。

    观察进度

    提交升级请求后，使用 cvsh.status 跟踪当前版本、期望版本、preflight 结果、各阶段和历史记录：

    kubectl get cvsh <cluster> -n cpaas-system
kubectl get cvsh <cluster> -n cpaas-system -o yaml

    如果当前 ACP context 指向目标业务集群，也可以检查 CLI 报告的状态：

    # Show summary, preflight, and stage progress for the target cluster upgrade
ac adm upgrade status

    有关 ac adm upgrade status 输出的详细含义（preflight 和阶段解读），请参见 升级集群。

    从 Marketplace 升级 Agnostic 插件

    CVO 负责驱动 Core 和 Aligned 插件。Agnostic 插件不在 CVO 的作用范围内，并且必须在此业务集群达到目标 Distribution Version 后逐个升级。

    对于此业务集群上每个正在使用的 Agnostic 插件：

    1. 在 Web Console 中切换到 Administrator 视图。
    2. 导航到用于 Agnostic 集群插件的 Marketplace > Cluster Plugins，或者进入 Agnostic operator 的 operator 工作流。
    3. 选择目标插件或 operator 并触发升级。

    每个 Agnostic 插件是否需要在本次窗口中升级，取决于其自身的 Kubernetes 兼容性——请参见该插件的 release notes，了解其与业务集群已达到的新 Kubernetes 版本的兼容性。

    如果 Marketplace 未在此业务集群上提供该 operator 的目标版本，请先为该 operator 完成 Operator push 回退，然后重试 Marketplace 升级。

    在排障时，请先检查条件、preflight 详情和历史记录：

    kubectl -n cpaas-system get cvsh <cluster> \
  -o jsonpath='{range .status.conditions[*]}{.type}{"\t"}{.status}{"\t"}{.reason}{"\t"}{.message}{"\n"}{end}'

kubectl -n cpaas-system get cvsh <cluster> \
  -o jsonpath='{.status.preflight.observedAt}{"\n"}{range .status.preflight.checks[*]}{.name}{"\t"}{.policy}{"\t"}{.state}{"\t"}{.reason}{"\t"}{.message}{"\n"}{end}'

kubectl -n cpaas-system get cvsh <cluster> \
  -o jsonpath='{range .status.history[*]}{.version}{"\t"}{.state}{"\t"}{.startedTime}{"\t"}{.completionTime}{"\n"}{end}'

    在所有业务集群都达到 ACP 4.3 之后

    在所有业务集群都达到 ACP 4.3 之后，请按照 禁用 PKCE Plain Method 完成 PKCE 安全加固。

    相关文档