EKS upgrade checklist: from 1.31 to 1.35 without breakage

The checklist at a glance

• List deprecated or removed APIs in manifests, Helm releases and the live cluster (pluto, kubent).
• Read the EKS upgrade insights and clear every ERROR and WARNING.
• Make sure nodes are on the same minor version as the control plane, and on an AMI that exists for the target.
• Note the compatible versions of VPC CNI, CoreDNS, kube-proxy, the EBS CSI driver and every Helm-installed controller.
• Find PodDisruptionBudgets that will block node drains.
• Check that the cluster subnets have at least five free IP addresses.
• Rehearse the full upgrade on staging and time each step.
• Write the rollback plan and decide up front: EKS rollback or blue/green.
• Upgrade the control plane by one version, then nodes, then add-ons. Repeat.
• After: smoke tests, update kubectl and pipelines, put the next deadline in the calendar.

1. Inventory: what will break

Deprecated APIs

The Kubernetes deprecated API migration guide is the reference. In the range most teams are dealing with in late 2026, version 1.32 stopped serving flowcontrol.apiserver.k8s.io/v1beta3 for FlowSchema and PriorityLevelConfiguration. Check the guide for every version you will cross. Two tools do the inventory:

# Installed Helm releases, against the target version
pluto detect-helm -owide --target-versions k8s=v1.35.0
# Manifests in the repository (Kustomize, plain YAML)
pluto detect-files -d ./deploy --target-versions k8s=v1.35.0
# Objects in the current cluster (active kubeconfig)
kubent

Pluto reads what is declared; kubent queries the cluster. Both rely on rule lists maintained by hand, so an empty result is a hint, not proof.

EKS upgrade insights

EKS checks each cluster itself: deprecated APIs actually called, kubelet version skew, add-on compatibility.

aws eks list-insights --cluster-name my-cluster \
  --filter categories=UPGRADE_READINESS
aws eks describe-insight --cluster-name my-cluster --id <insight-id>

Insights refresh every 24 hours, and you can trigger a manual refresh. A client you fixed yesterday may still show up today.

Nodes and AMIs

Kubernetes 1.32 is the last version for which EKS released Amazon Linux 2 AMIs, and EKS stopped publishing AL2 AMIs on November 26, 2025. Moving to 1.33 or later means nodes on Amazon Linux 2023 or Bottlerocket. That OS migration, with its user-data scripts and agents, deserves its own test.

2. Add-ons: VPC CNI, CoreDNS, kube-proxy, EBS CSI

Upgrading the control plane doesn't upgrade add-ons. For each, look up the versions compatible with the target:

aws eks describe-addon-versions --addon-name kube-proxy \
  --kubernetes-version 1.35 \
  --query "addons[].addonVersions[].addonVersion" --output text

Then, once the control plane and nodes are upgraded:

aws eks update-addon --cluster-name my-cluster \
  --addon-name kube-proxy --addon-version <version> \
  --resolve-conflicts PRESERVE

Repeat for vpc-cni, coredns and aws-ebs-csi-driver. Components installed outside EKS add-ons, usually with Helm (AWS Load Balancer Controller, cluster-autoscaler, metrics-server, cert-manager, your ingress controller), have their own compatibility matrices. Read them before the hop, not after. AWS also lists the cluster-autoscaler, the NVIDIA device plugin and kubectl among the components to update yourself.

3. Nodes: managed node groups, Karpenter, Auto Mode, Fargate

• Managed node groups: aws eks update-nodegroup-version replaces nodes in waves and respects PodDisruptionBudgets.
• Karpenter: nodes whose EC2NodeClass now resolves to a different AMI are considered drifted and replaced through the eviction API, so PDBs apply. Pods annotated karpenter.sh/do-not-disrupt block it. Check that your Karpenter version supports the target Kubernetes version.
• EKS Auto Mode: nodes are updated after the control plane, respecting PDBs.
• Fargate: existing pods keep their version until they are redeployed.

4. PodDisruptionBudgets

A badly set PDB blocks drains and makes a node group update fail. Look for the ones that allow no disruption:

kubectl get pdb -A

An ALLOWED DISRUPTIONS value of 0 means either a minAvailable equal to the replica count or an application that is already degraded. The classic case is a single-replica deployment with minAvailable: 1. Scale it to two replicas for the upgrade, or accept the interruption on purpose. Don't delete PDBs to get through.

5. One minor version at a time

EKS upgrades one minor version per operation: from 1.31 to 1.35 is four full cycles. Once a control plane upgrade starts, it can't be paused or stopped. It needs up to five free IP addresses in the subnets you gave the cluster at creation.

aws eks update-cluster-version --name my-cluster --kubernetes-version 1.32
aws eks describe-update --name my-cluster --update-id <update-id>

Before each control plane hop, managed and Fargate nodes have to be on the same minor version as the control plane. Since Kubernetes 1.28 the kubelet can be up to three minor versions behind the API server, but leaning on that just piles the risk up at the end. Wait for nodes, add-ons and tests to be green between hops.

6. Rehearse on staging

A rehearsal is only worth something if staging looks like production: same infrastructure code, same charts at the same versions, same add-ons, same node types. Without a staging cluster, a short-lived copy built from the same Terraform will do. During the rehearsal, time each step to size a realistic window, commit every manifest fix to the repository instead of patching the cluster by hand, and run smoke tests after each hop, not only at the end.

7. The rollback plan

Since July 1, 2026, EKS can roll a cluster back to the previous minor version. The conditions, from the AWS documentation:

• you must start the rollback within 7 days of the upgrade completing;
• the cluster must have reached its version through an in-place upgrade, and you can go back by one minor version only;
• add-ons are not rolled back automatically, and managed node groups have to be rolled back separately, before the control plane;
• Fargate nodes can't be rolled back;
• a cluster upgraded automatically at the end of extended support can't be rolled back.

For a single hop on a cluster you can rebuild, EKS rollback plus a rehearsal is a reasonable plan. For several hops in a row on a critical cluster, a blue/green cluster, built from the same Terraform on the target version and switched over at the load balancer or DNS, is still the safer net. Decide which before you start.

8. After the upgrade

• Smoke tests on every critical path, plus a look at error rates and latency.
• Update kubectl (within one minor version of the control plane) and CI images that bundle it.
• Re-run pluto and the insights for the next version, so the next upgrade starts with a list.
• Put the next end of standard support in the calendar, 90 days early. The cost of missing it is $0.50 per cluster-hour.

KubePrune is independent and not affiliated with Amazon Web Services. Prices are AWS public list prices checked on November 3, 2026; check the pricing pages for your region and date.

Frequently asked questions

Sources

Related