AWS EKS Support
EKS version upgrade: plan, test and run it without downtime.
Kubernetes versions leave standard support on a schedule, and EKS only upgrades one minor version at a time with no way back for the control plane. Surprises come from removed APIs, add-on versions and workloads that cannot tolerate node replacement. We find those before the upgrade starts.
When You Need This
The situations where this work pays for itself.
Signs it is time
- Your EKS version is nearing the end of standard support
- You have never upgraded the cluster and are several versions behind
- A manifest or Helm chart uses an API removed in a newer Kubernetes version
- Nodes run older AMIs and skew is growing
- You must prove an upgrade is safe before change approval
What you get
- Upgrade path with risks per version
- List of removed API usage and the fixes
- Staging rehearsal results and timing
- Runbook and executed production upgrade with verification
How we do it
A clear, safe process you can follow along with.
1. Read release notes and EKS upgrade insights
We read the Kubernetes and EKS release notes for each version in the path, and the cluster upgrade insights in the EKS console, which flag issues such as use of removed APIs seen in the audit logs.
2. Find deprecated and removed APIs
We scan live objects and Helm releases or manifests with tools such as kubent or Pluto, and update charts, operators and CRDs. Third-party controllers like ingress controllers and service meshes often need upgrading first.
3. Check add-on compatibility
We list the supported add-on versions for the target Kubernetes version, including VPC CNI, CoreDNS, kube-proxy and the EBS CSI driver, and plan the order of updating them, usually after the control plane.
4. Rehearse in a non-production cluster
We upgrade a staging cluster that mirrors production add-ons and workloads, run smoke and load tests, and measure how long node rolling takes.
5. Make workloads upgrade safe
We check replica counts, PodDisruptionBudgets, readiness probes, topology spread and graceful shutdown so rolling nodes does not cause an outage. Single replica deployments are fixed or scheduled.
6. Upgrade the control plane, add-ons, then nodes
We upgrade the control plane to the next minor version, update the add-ons, then roll managed node groups, Karpenter nodes or self-managed nodes to the matching AMI, watching errors. Each minor version is a separate change.
7. Verify and clean up
We confirm node and add-on versions, check that applications are healthy, review the next version in the path, and note the new support end date so the next upgrade is scheduled early.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Skipping minor versions
EKS does not allow skipping, and trying wastes time.
Upgrading nodes before checking skew
Keep nodes within the Kubernetes version skew policy and upgrade them soon after the control plane.
Ignoring PodDisruptionBudgets
A too-strict PDB blocks node drains, and none at all can take a service down.
Leaving it until end of support
Clusters on versions beyond standard support can incur extra cost. Check current EKS support policy and pricing.
Frequently Asked Questions
Can I roll back an EKS upgrade?
No. The control plane cannot be downgraded after an upgrade, so testing in a staging cluster and a backup plan matter. Nodes and workloads can be rolled back separately.
How long does an EKS upgrade take?
The control plane upgrade usually takes a while, and node rolling depends on cluster size and disruption budgets. We time it in staging first.
Does an EKS control plane upgrade cause downtime?
The API server stays available during a managed upgrade in normal cases, but controllers may briefly see disruption. Workloads keep running if they do not depend on the API continuously.
Want Help With EKS version upgrade: plan, test and run it without downtime?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required