Skip to main content
Cloud DevOps Solutions
Get a quote Talk to an engineer

EKS Cluster Upgrades

We upgrade your Amazon EKS cluster safely, from compatibility audit through staging validation to production rolling update, with rollback checkpoints at each step.

Book a working session Request a quote

Problems we solve

  • Running an EKS version that is out of standard support, with unpatched CVEs
  • Fear of breaking API removals (e.g. deprecated PodSecurityPolicy, Ingress v1beta1)
  • No tested upgrade runbook, the last upgrade caused unplanned downtime
  • Add-ons (CoreDNS, kube-proxy, VPC CNI) lagging behind the control plane version
  • No staging cluster to test the upgrade before touching production

What's included

Pre-upgrade compatibility audit: deprecated APIs, add-on versions, and custom webhooks
Upgrade runbook with rollback checkpoints
Staging cluster upgrade and validation (if required)
Control plane and managed node group upgrade execution
Add-on version updates: CoreDNS, kube-proxy, VPC CNI, EBS CSI, Load Balancer Controller
Post-upgrade smoke tests and monitoring validation
Documentation of changes and updated runbook

Our approach

  1. 01

    Compatibility audit

    We run pluto and kubent to detect deprecated and removed API versions in use. We check add-on compatibility matrices and identify any custom admission webhooks that need updates.

  2. 02

    Staging upgrade

    We upgrade a staging cluster one minor version at a time and run your full test suite. This helps validate the upgrade before any production change.

  3. 03

    Control plane upgrade

    AWS manages the control plane upgrade. We monitor API server availability and watch for any degraded nodes during the rollover.

  4. 04

    Node group rolling update

    We update managed node groups with a rolling update that respects PodDisruptionBudgets. Drain, upgrade, validate, repeat.

  5. 05

    Add-on and validation

    CoreDNS, kube-proxy, VPC CNI, EBS CSI, and Load Balancer Controller are updated to compatible versions. Full smoke test suite runs before sign-off.

Tech stack

Amazon EKSplutokubentHelmTerraformkubectlAWS Managed Add-onsKarpenter

Results

We publish results only when a client has approved them. See how we publish case studies and a sample report.

FAQ

How often should we upgrade EKS?
AWS supports each Kubernetes minor version on EKS for a limited period of standard support, followed by paid extended support, so check the current EKS version lifecycle in the AWS documentation. We recommend upgrading regularly rather than falling far behind.
Can we skip minor versions?
No. Kubernetes requires sequential minor version upgrades (e.g. 1.26 -> 1.27 -> 1.28). Each upgrade is a separate operation.
What is the downtime risk?
Control plane upgrades are managed by AWS. Node group rolling updates respect PodDisruptionBudgets, so properly configured applications should see little or no downtime. Misconfigured PDBs are a common cause of upgrade incidents.
What are deprecated API removals?
Each Kubernetes version removes APIs that were deprecated in earlier versions. For example, 1.25 removed PodSecurityPolicy and 1.22 removed Ingress v1beta1. We detect these before the upgrade and update your manifests.
Do you support self-managed node groups?
Yes, but we recommend migrating to managed node groups during the upgrade as they simplify the rolling update process.

Related services

Related articles

Ready to get started?

Book a free technical consultation. No commitment, just an honest conversation about your goals.

Book a working session Request a quote
Written by Saddique Khan, AWS & Azure Certified · Last updated October 2025