Upgrading EKS from 1.31 to 1.34: what breaks at each step.

There is no direct jump. Each hop is its own control-plane update, and once one starts you can't pause or stop it. If it goes wrong, EKS lets you roll back to the previous version within 7 days. If AWS upgrades the cluster for you at the end of extended support (the November 26 hop), you can't roll it back. Rollback also reverts only the control plane: you roll back managed node groups and add-ons yourself, before it. Every hop also needs free IP addresses in the cluster subnets.

• Plan three change windows, not one. Each hop is: control plane, then nodes, then add-ons, then clients.
• Start the first hop well before November 26, or AWS starts it for you.
• Each hop is aws eks update-cluster-version --name <cluster> --kubernetes-version 1.32 (then 1.33, then 1.34).

Kubernetes tolerates kubelets up to three versions behind, but EKS is stricter: managed node groups and Fargate must match the control plane before the next update. AWS recommends the same for self-managed and hybrid nodes. If you skip the node roll after 1.32, the 1.33 hop is blocked.

• After each control-plane hop, update every managed node group: aws eks update-nodegroup-version --cluster-name <cluster> --nodegroup-name <group>.
• Roll self-managed nodes and Karpenter NodePools onto the new AMI.
• Delete and recreate Fargate pods so they come back on the new version.

Every node group update drains nodes. A PodDisruptionBudget that allows no disruptions stops the drain, for example minAvailable equal to the replica count, or a single replica with minAvailable: 1. Three hops means three node rolls.

Scale those workloads to at least two replicas, or loosen the budget, before the window. --force on the node group update ignores budgets: use it only as a last resort.

During a node roll the webhook's own pods get evicted. A webhook with failurePolicy: Fail and no ready backend rejects every request it matches. That can block pod creation across the cluster, sometimes including the pods that would bring the webhook back.

• Give each fail-closed webhook at least two replicas, a PodDisruptionBudget and spread across nodes.
• Exclude kube-system with a namespaceSelector.
• Update the webhook's chart (cert-manager, Kyverno, Gatekeeper, AWS Load Balancer Controller) to a release that supports the target version before each hop.

VPC CNI, CoreDNS and kube-proxy each have a default version per Kubernetes version, and kube-proxy has to stay within the version skew. Third-party add-ons publish their own support ranges: cluster-autoscaler, Karpenter, ingress controllers, CSI drivers, service meshes. EKS upgrade insights flags some of this. It doesn't check third-party charts.

• After each control-plane hop and node roll, move VPC CNI, CoreDNS and kube-proxy to the default version for the new Kubernetes version.
• Check each third-party chart's support matrix before the hop, not after.
• Pass your add-on configuration explicitly on every update. An add-on update can reset fields you set by hand, such as the IAM role on the aws-node service account.

Manifests and Helm charts that still apply flowcontrol.apiserver.k8s.io/v1beta3 fail after the hop. Objects already in the cluster survive, because the API server stores them in a newer version. What breaks is the next deploy.

Change apiVersion to flowcontrol.apiserver.k8s.io/v1 in every manifest and chart. v1 has been served since 1.29 with the same fields, so you can do it today, before the hop.

From 1.32, EKS allows anonymous requests only to /healthz, /livez and /readyz. Anything that calls the API without credentials stops working, such as a probe that reads /version or a binding that grants system:unauthenticated access.

Give those callers credentials: a ServiceAccount token inside the cluster, or an IAM identity with an EKS access entry outside it.

Pods with securityContext.fsGroup that mount a ReadWriteOncePod volume get the volume's files re-owned on the first mount after the upgrade. This already happens for ReadWriteOnce. An app that relied on the old ownership can fail to read its own data, and a large volume can take a long time to mount.

Check that those apps tolerate the new ownership. Set fsGroupChangePolicy: OnRootMismatch to avoid a full recursive chown on every mount.

Only matters if your node config sets evictionSoft and evictionMaxPodGracePeriod. Soft-evicted pods now get the shorter of their own grace period and the eviction value. Before, they always got the eviction value, so pods with a short grace period now stop faster under memory pressure.

Usually nothing to do. If a workload needs more time to shut down, raise its terminationGracePeriodSeconds.

Nothing breaks at this hop, but the next one does. Use the time on 1.32 to move node groups to AL2023 or Bottlerocket, so the 1.33 hop is only a version change.

See the first item of step 2.

Managed node groups on an AL2 AMI type (AL2_x86_64, AL2_x86_64_GPU, AL2_ARM_64) can't follow the control plane to 1.33. While they stay on 1.32, the control plane can't move on to 1.34. This is usually the biggest piece of work in the whole path. AL2023 boots with nodeadm instead of bootstrap.sh, so custom user data has to be rewritten.

• Still on 1.32, create AL2023 or Bottlerocket node groups, move the workloads over, then delete the AL2 groups.
• For Karpenter, point the EC2NodeClass amiSelectorTerms at an al2023@ alias.
• Rewrite user data from bootstrap.sh flags to a nodeadm NodeConfig, and test one node before rolling the rest.

The changelog lists this under 1.32, but the gate was turned back off in 1.32.2 and is on by default from 1.33, so on EKS it bites at this hop. A CSI driver that uses workload tokens, such as the Secrets Store CSI driver, fails to mount if its CSIDriver object doesn't list the audience in tokenRequests.

Upgrade the CSI driver to a release whose CSIDriver object declares its tokenRequests audiences, before the hop.

The feature is on by default in 1.33. A pod that asks for Strict and lands on a node whose container runtime can't do it now fails on that node instead of running with merged groups.

Keep Strict pods on nodes that report true (containerd 2.0 or later), or drop the setting until every node does.

networking.k8s.io/v1 ServiceCIDR objects are served from 1.33. Any principal with create rights on them, including a broad * ClusterRole, can add Service IP ranges that may overlap your VPC.

Limit who can create ServiceCIDR objects with RBAC, or add a ValidatingAdmissionPolicy that rejects new ranges.

New pods whose nodeAffinity uses Gt or Lt with a non-integer value, or In or NotIn with an invalid label value, are rejected. Running pods keep running, but the workload can't roll or scale.

Fix the pod templates before the hop.

Only matters if a controller or script resizes running pods. Tools that wait on status.resize never see it set, in-place memory decreases are rejected, and resizePolicy can't be changed after the pod exists.

Read the PodResizeInProgress and PodResizePending conditions instead. Set resizePolicy for memory to RestartContainer when the pod is created, if you need to lower memory in place.

Nothing stops working, but clients that read Endpoints now get deprecation warnings. Endpoints also stop at 1000 addresses, so large Services already look incomplete to them.

Move controllers, meshes and monitoring to discovery.k8s.io/v1 EndpointSlice as you update them.

It still works. It won't become GA, so plan to move off it.

Replace the annotation with spec.trafficDistribution: PreferClose.

Nothing breaks: EKS didn't serve the DRA API before 1.33. If you don't run a DRA driver, skip this and the DRA item in step 3.

• If you adopt DRA now, use a driver and clients on resource.k8s.io/v1beta2: v1beta1 is deprecated.
• Put claims with adminAccess: true only in namespaces labelled resource.k8s.io/admin-access: "true". 1.34 renames that label (step 3).

Most EKS nodes run no static pods. On self-managed nodes or custom AMIs that drop manifests into the kubelet's static pod path, a static pod that uses a ConfigMap, Secret, PVC or ServiceAccount stops running once the node is on 1.34.

Inline the values in the manifest (literal env, hostPath) or run the pod as a DaemonSet before the node roll.

The 1.34 AMIs ship containerd 2.1. Test anything that touches the runtime before the fleet rolls: user data that writes /etc/containerd/config.toml, registry mirror settings, and very old images in the Docker schema 1 format.

Launch one 1.34 node from your launch template, run a representative workload on it, then roll the rest. AWS points to the containerd 2.1 release notes if something breaks.

Admission policies (Kyverno, Gatekeeper) and audits that read the container.apparmor.security.beta.kubernetes.io/ annotations stop seeing profiles on pods that set them through securityContext.appArmorProfile.

Move policies and manifests to the securityContext.appArmorProfile fields. AWS suggests seccomp or Pod Security Standards for new work.

Until 1.34, any value of node.kubernetes.io/exclude-from-external-load-balancers kept a node out of cloud load balancers. Now only a value other than false does. Nodes carrying =false become load balancer targets.

Remove the label, or set it to true where you meant to exclude the node.

This is why the path goes one version at a time. EKS can't skip 1.33, but a pod created on 1.32 and never recreated is in the same position as a skipped version: its selector was never merged, and the 1.34 scheduler no longer corrects for it, so spreading can drift.

Restart workloads that use matchLabelKeys after the 1.33 hop (kubectl rollout restart). Controllers that read labelSelector back should expect the extra In requirements.

A stale nomination now stays on a pending pod until something else clears it, for example after the nominated node is deleted.

Run a Cluster Autoscaler or Karpenter release that supports 1.34 before the hop.

A container without its own limits that reads limits.cpu or limits.memory through the Downward API now sees the pod's limits instead of the node's capacity. JVM heap or GOMAXPROCS sizing built on that value changes.

Set container-level limits where the old value was intended.

Only matters if you change EBS volume type or IOPS through a VolumeAttributesClass. While you are on 1.32 or 1.33, newer self-managed csi-provisioner and csi-resizer sidecars expect the GA API, so volume modification can stop working partway through the path. AWS patched its managed sidecars for the beta API only until July 29, 2026.

Keep the sidecars on versions that speak v1beta1 until the 1.34 hop, then upgrade them and move VolumeAttributesClass manifests to storage.k8s.io/v1.

• A driver built only for the v1alpha4 kubelet API isn't registered on 1.34 nodes, and its devices disappear.
• Claims with adminAccess in a namespace that has only the old label are rejected.
• Scheduling a pod with a complex claim now times out after 10 seconds (FilterTimeout).

• Upgrade every DRA driver to a release built on the 1.32 or newer kubelet plugin helper before the node roll.
• Add resource.kubernetes.io/admin-access: "true" next to the old label, upgrade, then remove the old one.
• Raise FilterTimeout in the scheduler's DynamicResources config only if pods stay Pending with a timeout.