Alauda Container Platform
  • 简体中文

    • 升级业务集群

    升级路径

    此页面介绍业务集群的传统操作系统路径。对于使用 Alauda OS 的业务集群，Kubernetes 步骤位于 Immutable Infrastructure 文档中——请参见 在 Immutable Infrastructure 上升级集群。本页面中描述的 Core、Aligned 和 Agnostic 步骤仍适用于 immutable-OS 集群；不同之处仅在于 Kubernetes 的发布方式。

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

    业务集群升级使用与 global 集群相同的基于 CVO 的工作流：确认先决条件、运行预检检查、发起升级并观察执行过程。该工作流还有两条附加规则：

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

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

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

    目录

    工作流验证升级相关文档

    工作流

    确认业务集群先决条件

    在请求升级之前，请验证以下内容：

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

    确保 Aligned operator 包可用

    升级 global 集群 中推荐的模式会在 global 升级窗口期间将 operator 包推送到每个 集群。如果已遵循该建议，则业务集群已经拥有所需的全部 operator 包，可以跳过此部分。

    cluster plugin 不需要按业务集群逐个发布。通过 upgrade.sh 或 violet 向全局层级提供的 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 推送包。向全局层级提供的 Aligned cluster plugin 包对所有业务集群都可用，因此不需要按集群逐个发布。

    如果已安装的 Aligned operator 的目标包不可用，CVO 可以等待匹配的目标 InstallPlan，然后在重试现有请求时报告错误。请检查该 operator 的 catalog、Subscription、InstallPlan 和 ModuleInfo；使用上述命令发布缺失的包，或修正报告中的 catalog 或 registry 问题。继续观察现有请求即可；无需重新提交。未安装在该业务集群上的 Aligned operator 的包不会阻塞其升级。

    运行预检检查

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

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

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

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

    预检返回两部分：

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

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

    有关预检阻塞处理模式，请参见 升级故障排除。

    请求升级

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

    通过以下任一入口请求升级。各入口等效；请选择最适合你操作模式的方式。

    平台在 Web Console 中提供两个集群管理界面。Web Console 是平台自带的内置界面，也是默认路径。Web Console (Fleet Essentials) 是更新的集群管理界面，作为单独的 cluster plugin 提供，必须先安装后才能使用。

    Web Console
    Web Console (Fleet Essentials)
    ACP CLI

    这是内置的集群管理界面。业务集群升级使用与 global 集群升级相同的页面，只是打开的是业务集群，而不是 global。

    发起升级需要对目标集群的 ClusterVersionShadow 和 ResourcePatch 资源具有更新权限。

    1. 在左侧导航栏中，点击 Clusters > Clusters，然后点击该业务集群。

    2. 打开 Functional Components 选项卡，然后点击 Upgrade。

      当没有可升级版本（No upgradable version）、升级已在进行中（Upgrading），或者集群不健康（Cluster Abnormality）时，该按钮会被禁用。只有在全局层级达到目标 Distribution Version 之后，业务集群才会有可升级版本。

    3. 在 Personalized Configuration Confirmation 步骤中，查看列出的配置，然后点击 Acknowledge。

      此步骤仅在集群包含个性化配置时出现——即自定义的 ModuleInfo、自定义的 ClusterModule 或 ResourcePatch。如果集群不包含这些内容，该步骤不会显示，页面会直接打开确认表单。

    4. 在 Confirm Component Upgrade 步骤中，查看 Current Version 和 Target Version。

      对于业务集群，目标版本是全局层级已经达到的 Distribution Version；在此界面中无法手动选择。

    5. 点击 Upgrade，然后在 Are you sure you want to upgrade the cluster version? 对话框中确认。

    默认启用维护模式，且会应用于整个平台

    该确认对话框与 global 集群升级共用，并且打开时 Maintenance mode 已经启用。此开关写入的是平台级维护模式设置，而不是业务集群设置：当其开启时，非平台管理员的用户将无法访问平台内的各项平台功能，并且他们会看到 Platform maintenance announcements 中的文本。除非你希望在该业务集群升级期间限制整个平台，否则在提交前请关闭该开关。

    请求提交后，页面会返回到 Functional Components 选项卡，并显示 The upgrade has been initiated. It may take 5~10 minute for the status to update.

    观察进度

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

    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 输出的详细语义（预检和阶段解释），请参见 升级集群。

    如果升级报告 Stalled=True，请使用 升级故障排除。缺失的 Aligned operator 包和 cluster-plugin 包具有不同的恢复路径。

    上述命令跟踪的是集群级别（Core 和 Aligned）的升级。要观察单个 plugin 或 operator 模块——例如在升级 Agnostic plugin 时——请读取其 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 plugin

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

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

    1. 在 Web Console 中切换到 Administrator 视图。
    2. 导航到 Marketplace > Cluster Plugins 以处理 Agnostic cluster plugin，或进入 Agnostic operator 的 operator 工作流。
    3. 选择目标 plugin 或 operator，并触发升级。

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

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

    验证升级

    在业务集群及其正在使用的 Agnostic plugin 达到各自目标后，完成 升级验证。

    相关文档