升级验证

在关闭维护窗口前,验证每个已升级的集群。在 global DR 环境中,分别验证备用和主 global 集群,然后再升级业务集群。对于 Alauda OS 集群,在 global 集群 或业务集群完成在 Alauda OS 上升级 Kubernetes 后,执行此验证。

确认 Distribution 版本和 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 版本和期望的 Distribution 版本都必须与目标版本匹配。Ready 必须为 True,Reconciling 不得再为 True,并且 Stalled 不得为 True。最新的历史记录项必须显示目标版本已成功完成。

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

从 global 集群管理上下文中,确认 Core 和已安装 Aligned 模块的状态:

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

然后,对已升级的集群使用 kubectl 上下文,确认 Kubernetes 服务器版本、节点就绪状态和 Pod:

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 模块必须在健康阶段报告目标版本;关键 Pod 必须为 Running 或 Completed。

验证已安装扩展的可用性

如果需要确认已升级的应用仍可被发现,请从 global 集群查看集群插件目录:

kubectl get moduleplugins

升级验收适用于已安装在升级集群上的 Core 和 Aligned 应用。使用前几节中的 ClusterVersionShadow 完成状态和 ModuleInfo 版本作为权威结果,并确认没有相关 Pod 报告 ImagePullBackOff 或 ErrImagePull。

无需要求 ProductBase.status.artifacts 中的每个条目都为 Ready。ProductBase 包含可选或未安装的目录软件包,包括 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 方法中的说明操作。

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