The EKS upgrade playbook

Two dates make this the month to write the playbook down. On July 23, 2026, Kubernetes 1.30 reaches the end of extended support on EKS, and AWS starts auto-upgrading whatever 1.30 control planes remain, at any time after that date, with no notification first. Six days later, 1.33 leaves standard support, and every cluster still on it starts billing at the extended-support rate: $0.60 per cluster-hour instead of $0.10. Over a year that’s $5,256 per cluster instead of $876, for standing still. Both dates come from AWS’s release calendar, which is worth reading the way you’d read a lease.

I promised this piece at the end of the stabilization article, and I’ve run this cycle on clusters that page. What follows is the playbook I actually use: the fears and which of them are still earned, the mechanics as AWS documents them today, and what’s waiting in each version from 1.31 to 1.36.

The scariest fact about upgrades expired

EKS upgrades get deferred because everyone remembers them being irreversible. That memory is out of date. EKS now supports rolling back an in-place upgrade to the previous minor within seven days, with rollback-readiness checks that run during the window. The caveats matter: a cluster AWS auto-upgraded at end of support can’t roll back, and rolling back into an extended-support version resumes extended billing. But the one-way door, the single most rational reason to fear the button, is gone.

Less known and also calming: the control-plane update itself is checked. AWS brings up new API server nodes at the target version and health-checks them, and per the update documentation, “if any of these checks fail, Amazon EKS reverts the infrastructure deployment, and your cluster remains on the prior Kubernetes version.” You can’t pause an update once it starts. A failed one still doesn’t strand you.

What still deserves respect is a shorter list. Deprecated API removals break manifests and controllers that have worked for years; 1.32 removed the flowcontrol.apiserver.k8s.io/v1beta3 versions of FlowSchema and PriorityLevelConfiguration, and anything still writing them fails after that bump. Node recycling collides with pod disruption budgets: a managed node group gives each node’s pods 15 minutes to leave, and if a PDB won’t release them, the upgrade fails with PodEvictionFailure (node update phases). The add-on matrix is real: VPC CNI, CoreDNS, kube-proxy, and cluster-autoscaler all have versions matched to the cluster minor, and none of them move on their own. And 1.33 hides an operating-system migration inside a Kubernetes upgrade: AWS stopped publishing Amazon Linux 2 AMIs after 1.32, so crossing that line means AL2023 or Bottlerocket, with different bootstrap behavior riding along with the version bump.

The playbook

1. Know your dates. aws eks describe-cluster-versions returns the support status and end-of-support dates for every version EKS offers. Put your clusters’ dates in the planning calendar, next to the certificate renewals.

2. Read the release notes for every minor you’ll cross. AWS keeps per-version notes for standard-support and extended-support versions, and the upstream deprecated API migration guide covers the removals. Reading three short pages beats discovering their contents in production.

3. Let EKS do the first audit. Upgrade insights run automatically on every cluster, refresh every 24 hours, and watch actual API traffic for deprecated usage. One timing gotcha: the deprecated-API check looks at a rolling 30-day window, so after you fix a caller it can take up to 30 days for the insight to clear. Green insights are a trailing indicator. Read them when you start planning, and again before the change window.

4. Fix skew before you move the control plane. Since Kubernetes 1.28 the kubelet may trail the API server by up to three minor versions. That allowance is the fleet-scale trick: walk the control plane up two or three minors, recycle nodes once. AWS’s written recommendation remains to bring nodes to the control plane’s minor before each update, and the conservative reading is the right default when stateful workloads are involved.

5. Move the control plane, one minor at a time. EKS will not skip minors. The update needs up to five free IP addresses in the subnets the cluster was created with, and it can fail if those subnets or their security-group rules have drifted since cluster creation. The control-plane update itself takes several minutes. The preparation is the actual work.

6. Recycle nodes deliberately. Managed node groups never follow the control plane on their own. The default update config replaces one node at a time, and the default strategy adds capacity before removing it; the minimal strategy exists for capacity-constrained pools like GPU fleets, where it terminates before it launches. Audit PDBs before the window: a single-replica deployment with minAvailable: 1 stalls the drain by construction, and after 15 minutes that’s a failed upgrade, with --force as the documented but blunt way through. If Karpenter manages your capacity, know that dynamic AMI selection (@latest) starts replacing nodes on its own after a control-plane bump, which is why Karpenter’s own docs heavily recommend against it in production. Pin AMIs and roll on your schedule, in both senses.

7. Then add-ons, then clients. VPC CNI, CoreDNS, and kube-proxy go to their recommended versions for the new minor; cluster-autoscaler goes to the release matching the Kubernetes minor; kubectl stays within one minor of the API server. This is the step that gets skipped when the upgrade “worked,” and it’s where the next upgrade’s surprises come from.

8. Rehearse in dev with production-shaped objects. This step has no citation because it’s practice, and it’s the one I’d keep if forced to pick: the same PDBs, the same webhooks, the same operators, the same node classes, upgraded the same way, before production. Nothing about a version bump should be novel by the time it reaches the cluster that matters.

What’s waiting in each version

1.31, in extended support until November 26, 2026: the kubelet flag --keep-terminated-pod-volumes is removed, so custom launch templates and bootstrap scripts still passing it break on the new AMI.

1.32, extended until March 23, 2027: the flowcontrol v1beta3 APIs are removed. Anonymous API access is restricted to /healthz, /livez, and /readyz, which flushes out RBAC misconfigurations that were silently tolerated before. This is the last version with AL2 AMIs.

1.33, standard until July 29, 2026: the first version with no AL2 AMI, so the AL2023-or-Bottlerocket migration is due here at the latest. The Endpoints API is officially deprecated in favor of EndpointSlices. Sidecar containers are finally stable.

1.34, standard until December 2, 2026: containerd 2.1 at launch. AppArmor is deprecated. VolumeAttributesClass goes GA, with EBS CSI sidecar-version caveats worth reading if you self-manage the driver.

1.35, standard until March 27, 2027: the kubelet refuses to start on cgroup v1 by default, so anyone who manually configured AL2023 back to v1 must undo that or set failCgroupV1: false. This is the last release supporting containerd 1.x, and IPVS mode in kube-proxy is deprecated. Separately, the Kubernetes project announced the retirement of Ingress NGINX for March 2026, with no further bug fixes or security patches after that and no drop-in replacement; if you run it, that migration is its own project with its own deadline.

1.36, on EKS since June 2, 2026: gitRepo volumes are permanently disabled, and the failure mode is quiet, because the API still accepts the pod while the kubelet refuses to run it. Strict IP/CIDR validation rejects leading-zero addresses and non-canonical CIDRs in new objects. Service externalIPs is deprecated.

Every line above comes from AWS’s release notes for standard and extended versions; the full upstream changelogs are linked from those pages.

The cadence is the playbook

Upstream ships a minor roughly every four months, and each one gets 14 months of standard support on EKS. A team that upgrades on a schedule, once or twice a year, never meets the extended-support bill or the auto-upgrade, and crosses one version’s worth of removals at a time with the insights already green. A team that waits for the console to show a deadline does the same work with three minors of changes at once, under time pressure, while finance asks about the new line item. The work doesn’t shrink when you defer it. It compounds.