Upgrades¶
AKS upgrades touch both Kubernetes version and node image lifecycle. A safe upgrade is a staged change with explicit pre-checks, workload validation, and rollback criteria.
Prerequisites¶
- Review supported versions and target version compatibility.
- Confirm workload manifests and controllers support the target version.
- Review maintenance windows, PDBs, and cluster autoscaler settings.
When to Use¶
- Moving to a supported Kubernetes version.
- Applying node image updates.
- Aligning cluster posture with security or support policy.
Procedure¶
flowchart TD
A[Check versions] --> B[Upgrade non-production]
B --> C[Upgrade control plane and pools]
C --> D[Validate workloads]
D --> E[Repeat in production]az aks get-upgrades --resource-group $RG --name $CLUSTER_NAME --output table
az aks upgrade --resource-group $RG --name $CLUSTER_NAME --kubernetes-version <target-version> --yes
kubectl get nodes
kubectl get pods -A
Verification¶
az aks show --resource-group $RG --name $CLUSTER_NAME --query kubernetesVersion --output tsv
kubectl version
kubectl get events -A --sort-by=.lastTimestamp
Rollback / Troubleshooting¶
- AKS does not offer a simple in-place downgrade path for every upgrade scenario, so test first.
- If workloads fail after upgrade, inspect API deprecations, CRD/controller compatibility, and PDB constraints.
- If one pool is problematic, isolate validation there before widening the rollout.