升级验证

在关闭维护窗口之前,验证每个已升级的集群。在 global DR 环境中,在升级工作负载集群之前,分别验证备用和主 global 集群。

确认 Distribution Version 和 CVO 完成情况

在 global 集群中,检查目标集群的 ClusterVersionShadow

kubectl -n cpaas-system get cvsh <cluster> \
  -o jsonpath='{.status.current.version}{"\t"}{.status.desired.version}{"\n"}{range .status.conditions[*]}{.type}{"\t"}{.status}{"\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}'

当前和期望的 Distribution Version 必须与目标版本一致。Ready 必须为 TrueReconciling 不应再为 True,且 Stalled 不能为 True。最新的 history 条目必须显示目标版本已成功完成。

验证 Kubernetes、节点、Core 和已对齐插件

在 global-cluster 管理上下文中,确认 Core 和已安装的 Aligned 模块状态:

kubectl get clustermodule <cluster> -o yaml
kubectl get moduleinfo -l cpaas.io/cluster-name=<cluster>

然后使用升级后集群的 kubectl 上下文,确认 Kubernetes server 版本、节点就绪状态以及 Pods:

kubectl version
kubectl get nodes
kubectl get pods --all-namespaces \
  | awk '{if ($4 != "Running" && $4 != "Completed")print}' \
  | awk -F'[/ ]+' '{if ($3 != $4)print}'

所有节点都必须处于 Ready;Core 和已安装的 Aligned 模块必须在健康阶段报告目标版本;关键 Pods 必须处于 RunningCompleted 状态。

验证已安装扩展的可用性

在 global 集群中,当你需要确认升级后的原生应用仍然可被发现时,请查看 cluster plugin 目录:

kubectl get moduleplugins

升级验收适用于实际安装在升级后集群上的 Core 和 Aligned 原生应用。请使用上一节中的 ClusterVersionShadow 完成状态和 ModuleInfo 版本作为权威结果,并确认没有相关 Pod 报告 ImagePullBackOffErrImagePull

不要要求 ProductBase.status.artifacts 中的每一项都必须为 ReadyProductBase 包含可选或未安装的目录包,包括 Agnostic 应用,这些项目在集群升级成功后合理地可能仍然保持 Absent

验证 Web UI 和正在使用的 Agnostic 插件

打开平台 Web UI,确认登录、集群页面和 Marketplace 页面可以正常加载。升级目标 Kubernetes 版本所需的每个正在使用的 Agnostic 插件,然后验证其 UI 和主要功能。

当从早于 ACP 4.3 的版本升级时,请使用与目标版本兼容的这些 Agnostic 插件,否则其页面可能无法打开:

  • Alauda DevOps v3
  • Alauda AI Essentials
  • Alauda Hyperflux
  • Alauda Container Platform Data Services Essentials

完成所有适用的产品特定流程:

如果源版本早于 ACP 4.3,且尚未完成 PKCE 加固,请等待 global 层和所有工作负载集群都达到目标 Distribution Version,然后按照 禁用 PKCE Plain 方法 进行操作。

如果任何验收检查失败,请保持维护窗口开启,并使用 升级故障排查