#Upgrade Validation

Validate each upgraded cluster before closing its maintenance window. In a global DR environment, validate the standby and primary global clusters separately before upgrading workload clusters.

#Confirm Distribution Version and CVO Completion

From the global cluster, inspect the target cluster's 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}'

The current and desired Distribution Versions must match the target. Ready must be True, Reconciling must no longer be True, and Stalled must not be True. The newest history entry must show the target version completed successfully.

#Validate Kubernetes, Nodes, Core, and Aligned Plugins

From the global-cluster management context, confirm the Core and installed Aligned module state:

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

Then use a kubectl context for the upgraded cluster to confirm the Kubernetes server version, node readiness, and Pods:

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

All nodes must be Ready; Core and installed Aligned modules must report the target version in a healthy phase; critical Pods must be Running or Completed.

#Validate Installed Extension Availability

From the global cluster, review the cluster plugin catalog when you need to confirm that an upgraded application remains discoverable:

kubectl get moduleplugins

Upgrade acceptance applies to the Core and Aligned applications actually installed on the upgraded cluster. Use the ClusterVersionShadow completion state and the ModuleInfo versions from the previous sections as the authoritative result, and confirm that no related Pod reports ImagePullBackOff or ErrImagePull.

Do not require every entry in ProductBase.status.artifacts to be Ready. ProductBase includes optional or uninstalled catalog packages, including Agnostic applications, which can legitimately remain Absent after a successful cluster upgrade.

#Validate the Web UI and In-Use Agnostic Plugins

Open the platform Web UI and confirm that login, cluster pages, and Marketplace pages load. Upgrade each in-use Agnostic plugin required for the target Kubernetes version, then verify its UI and primary function.

When upgrading from a release earlier than ACP 4.3, use target-compatible versions of these Agnostic plugins or their pages can fail to open:

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

Complete any product-specific procedures that apply:

• Upgrade Alauda AI
• Upgrade Alauda DevOps

If the source release is earlier than ACP 4.3 and PKCE hardening has not already been completed, wait until the global tier and all workload clusters reach the target Distribution Version, then follow Disabling the PKCE Plain Method.

If any acceptance check fails, keep the maintenance window open and use Upgrade Troubleshooting.