Skip to main content

​
Overview

Xloud K8SaaS supports rolling Kubernetes version upgrades. Master nodes are upgraded first, followed by sequential worker node replacement — draining each node before removing it and adding a replacement with the new version. This approach maintains cluster availability throughout the upgrade process.
Kubernetes does not support skipping minor versions. Upgrade sequentially through each minor version (e.g., 1.27 → 1.28 → 1.29). Attempting to skip a version (e.g., 1.27 → 1.29 directly) is not supported and will fail.
Prerequisites
  • A cluster in CREATE_COMPLETE or UPDATE_COMPLETE status
  • A cluster template with the target Kubernetes version available in your project
  • Sufficient compute quota to temporarily run extra nodes during the rolling replacement

​
Pre-Upgrade Checklist

Verify the target template exists

Confirm a cluster template with the target Kubernetes version is available:
List available templates
openstack coe cluster template list
If the target version template does not exist, ask your administrator to create a public template or create a private one in your project.

Check cluster health

Verify cluster is healthy
openstack coe cluster show prod-cluster-01 \
  -f value -c status -c health_status
Proceed only when status = CREATE_COMPLETE or UPDATE_COMPLETE and health_status = HEALTHY.

Verify node readiness

Check all nodes are Ready
kubectl get nodes
All nodes must show STATUS: Ready before starting the upgrade.

Notify application teams

Inform application owners that the cluster will undergo a rolling upgrade. While the upgrade is non-destructive, pods will be evicted during node replacement. Ensure workloads use multiple replicas and have Pod Disruption Budgets configured.

​
Perform the Upgrade

Navigate to the cluster

Log in to the Xloud Dashboard (https://connect.<your-domain>) and navigate to Project → Containers → Clusters. Click your cluster name.

Start upgrade

Click Actions → Upgrade Cluster. Select the target cluster template with the desired Kubernetes version and confirm.

Monitor progress

The cluster enters UPDATE_IN_PROGRESS status. The upgrade progresses through:
  1. Master nodes upgraded first (one at a time for HA clusters)
  2. Worker nodes drained and replaced sequentially
Use kubectl get nodes -w to watch node status changes in real time during the rolling replacement.

Verify completion

The cluster returns to UPDATE_COMPLETE when all nodes are on the new version.
All nodes show the new Kubernetes version in kubectl get nodes.

​
Post-Upgrade Validation

After upgrade completes, verify:
  • Cluster shows Health Status: HEALTHY
  • All nodes listed in the cluster detail show STATUS: Ready
Cluster is healthy and all nodes are at the target version.

​
Next Steps

Troubleshooting

Resolve upgrade failures and post-upgrade issues.

Node Groups

Manage specialized node pools after an upgrade.

Kubernetes Admin Guide — Certificates

Rotate cluster CA certificates after major version upgrades.

Access Cluster

Refresh kubeconfig after a cluster upgrade if the CA was rotated.