Upgrade Clusters

Upgrade a managed cluster while keeping the rollout predictable.

What changes during an upgrade

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

Expected behaviour:

• 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.

The upgrade targets control-plane and API compatibility. It does not touch your application rollout.

Version availability policy (N-2)

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.
• The operator supports the three most recent minor versions (N, N-1, N-2).
• 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 behaviour

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

• Kupe gives advance notice as your running version approaches deprecation/end-of-support.
• Support can help you plan or execute an upgrade: sequencing, validation checkpoints, and reducing risk for a production window.

Further reading

• Kubernetes version skew policy