Upgrade Clusters

Use this guide to complete Kubernetes version upgrades safely and predictably.

What changes during an upgrade

Cluster upgrades update the Kubernetes control plane/API version for your managed cluster.

Expected behavior:

• Workloads continue running during the upgrade.
• Data plane workloads are not re-deployed just because the control plane version changes.
• You may see short-lived API/control-plane reconnections while components roll.

In short: the upgrade targets cluster control-plane/API compatibility, not application rollout changes.

Version availability policy (N-3)

Supported versions follow a rolling window in the console based on platform-supported Kubernetes releases.

• You can select from the current supported window, shown directly in the cluster version selector.
• Support window follows an N-3 policy for minor versions.
• Upgrades are one minor version at a time.
• Downgrades are not supported.

If your current version approaches end-of-support, you’ll receive advance notice to plan the upgrade window.

Before you start

1. Review release notes for your target Kubernetes minor version.
2. Upgrade lower environments first (dev -> staging -> production).
3. Freeze non-essential app changes during the upgrade window.
4. Confirm dashboards and alerting are healthy before you start.
5. Confirm workloads are currently stable (Ready, no active incident).

Upgrade process (console)

1. Open the cluster in the console.
2. Go to the Kubernetes version/upgrade action.
3. Select the next target version from the supported list.
4. Confirm the upgrade.
5. Monitor cluster phase until it returns to Running.

What to monitor during upgrade

• Cluster phase/state transitions in the console.
• API responsiveness (kubectl get ns, kubectl get pods -A).
• Application error rate and latency in Grafana.
• Namespace events for repeated warnings.

Post-upgrade validation checklist

Run these checks immediately after phase returns to Running:

kubectl get nodes
kubectl get pods -A
kubectl get events -A --sort-by=.lastTimestamp

Confirm:

• Cluster reports healthy and stable.
• Critical workloads remain Ready.
• No new recurring error events (mount failures, probe failures, scheduling errors).
• Error/latency/saturation metrics are within normal baseline.

If the upgrade regresses behavior

1. Pause new releases.
2. Identify impacted namespaces/services quickly.
3. Verify whether regression is from workload changes vs cluster upgrade window.
4. Contact support with:
   • Cluster name
   • Target version
   • Time upgrade started/completed
   • Key events/logs/metrics

Deprecation notices and upgrade assistance

• Advance notice is provided for versions moving toward deprecation/end-of-support.
• If you need help planning or executing upgrades, support can assist with sequencing, validation checkpoints, and risk reduction for production windows.

Further reading

• Kubernetes version skew policy