Alauda Container Platform
  • 简体中文

    • 升级业务集群

    升级路径

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

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

    MySQL-PXC 已移除，自 Alauda Database Service for MySQL v4.3.0 起生效。升级到 ACP v4.3.0 或更高版本后，现有 PXC 实例将不再由 MySQL operator 管理。升级前请参见 MySQL Operator 升级指南 了解迁移说明。

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

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

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

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

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

    目录

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

    工作流

    确认业务集群前提条件

    在请求升级之前，请确认以下内容：

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

    确保 Aligned operator 包可用

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

    cluster plugin 不需要按业务集群逐个推送。只要在 global 层推送一次 cluster plugin，即可在平台内的每个集群上安装和升级。

    如果 global 窗口没有将 operator 包推送到该业务集群——例如，该集群在 global 窗口期间处于离线状态，或者是之后才新增的——请在发起升级请求之前，为该业务集群上安装的每个 Aligned operator 推送目标版本包：

    violet push <path/to/operator-package> \
  --platform-address "https://<your-platform-domain>" \
  --platform-token "<platform_token>" \
  --clusters "<workload-cluster-name>"

    只需为业务集群上实际安装的 Aligned operator 推送包即可。发布到 global 层的 Aligned cluster plugin 包对所有业务集群都可用，无需按集群逐个推送。

    如果已安装的 Aligned operator 的目标包缺失或未就绪，CVO 会使业务集群升级停滞。请使用上述命令发布缺失的包，然后继续观察现有请求。CVO 会检测到新就绪的包并自动恢复；无需重新提交升级请求。未在该业务集群上安装的 Aligned operator 的包不会阻塞其升级。

    运行预检检查

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

    以预检模式针对目标集群运行 upgrade.sh：

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

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

    预检返回两部分内容：

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

    如果预检未通过，请在所有阻塞项解决之前不要提交升级请求。

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

    请求升级

    时间： 维护窗口期间，并且在预检通过之后。

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

    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 跟踪当前版本、目标版本、预检结果、阶段和历史记录：

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

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

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

    有关 ac adm upgrade status 输出的详细语义（预检和阶段解释），请参见 升级集群。

    如果已安装的 Aligned operator 没有向其目标版本推进，请验证该 operator 的目标包是否已按 确保 Aligned operator 包可用 所述推送到该业务集群。如果某个 Stalled 条件指出缺少或未就绪的 ModulePluginConfig，则缺失的组件是一个 cluster plugin；请按 升级 global 集群 中的说明，将其包一次性发布到 global 层。

    上述命令跟踪的是集群级别（Core 和 Aligned）的升级。要观察某个单独的插件或 operator 模块——例如在升级 Agnostic 插件时——请读取其 ModuleInfo：

    kubectl get moduleinfo -l cpaas.io/cluster-name=<cluster> \
  -o custom-columns='MODULE:.metadata.labels.cpaas\.io/module-name,CURRENT:.status.version,TARGET:.spec.version,NEW:.status.availableVersions[0].version,PHASE:.status.phase'

    当 status.phase 为 Running 且 status.version 等于目标版本时，该模块即已达到目标。

    从 Marketplace 升级 Agnostic 插件

    CVO 驱动 Core 和 Aligned 插件。Agnostic 插件不在 CVO 的范围内，必须在该业务集群达到目标 Distribution Version 后单独升级。

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

    1. 在 Web Console 中切换到 Administrator 视图。
    2. 对于 Agnostic cluster plugins，导航到 Marketplace > Cluster Plugins；对于 Agnostic operators，导航到 operator 工作流。
    3. 选择目标插件或 operator 并触发升级。

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

    如果 Marketplace 没有提供该业务集群上某个 operator 的目标版本，请先按照 确保 Aligned operator 包可用 的说明为该 operator 处理，然后重试 Marketplace 升级。

    排查问题时，请首先检查 conditions、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 安全加固。

    相关文档