The order is fixed because each layer depends on the one above it.

Nodes may lag the control plane within the supported skew, but never lead it. Add-ons must support the new version first.

the sequence in commands

$ aws eks update-cluster-version --name shop-eu --kubernetes-version 1.32
$ aws eks update-addon --cluster-name shop-eu --addon-name vpc-cni --resolve-conflicts PRESERVE
$ aws eks update-nodegroup-version --cluster-name shop-eu --nodegroup-name std

Study notes

Upgrade in order: control plane, add-ons, then nodes

EKS upgrades follow a strict order because of dependencies. First the control plane, one minor version at a time; AWS replaces API servers in a rolling fashion so running workloads continue, with a brief period where the API may be slow or briefly unavailable. Second the managed add-ons to versions that support the new control plane, using PRESERVE. Third the nodes. Nodes may be older than the control plane within the supported skew, but never newer. Press the right arrow to step through.

Preparation matters more than the commands. Before touching anything check deprecated API usage, make sure PodDisruptionBudgets will not block drains, confirm add-on compatibility, make sure the cluster subnets have a few free IP addresses (the control plane upgrade needs them), and take a backup. After the upgrade verify with your service-level objectives, not just kubectl get nodes.

Run the same procedure in a staging cluster created from the same Terraform, then upgrade production in rings (for example internal, then low-risk, then critical clusters) with time between them. There is no downgrade path for the control plane, which is why rehearsal and ring rollout are the real safety net.

Auto Mode changes the node step: AWS rotates nodes for you. With Karpenter, node upgrades happen through drift when the AMI changes, which brings its own risk if you use a floating latest alias; see the next slide.

Back Next