Kubernetes, EKS and OpenShift version upgrades
Cohash upgrades Kubernetes on Amazon EKS, AKS and Red Hat OpenShift and puts a cadence in place so clusters don't drift again. Before any change, manifests and Helm charts are scanned for removed APIs and each add-on and operator is checked against the target version. We upgrade a non-production cluster first, then move control planes and node pools one minor at a time. Clusters on extended support get a dated exit plan.
- 01Cluster and add-on inventory
- 02Deprecated API and chart scan
- 03Rehearse on non-production
- 04Control plane, then nodes
- 05Cadence and automation
The story
Told without the client's name or anything that could identify them.
A logistics company's platform team had EKS and OpenShift clusters drifting behind, with an extended support line on the AWS bill and node groups on a different minor from their control planes. Past upgrades had broken an ingress controller or an operator, so each new one kept getting deferred. We inventoried every cluster, add-on and operator, scanned manifests and Helm releases for removed APIs, and gave each workload owner a fix list. A staging cluster with the same add-ons went first, then control planes and node groups moved one minor at a time. Cluster versions now live in Terraform and GitOps, and the next upgrade is on the calendar before the current one closes.
why it was urgentKubernetes ships a minor roughly every four months. On EKS, each gets 14 months of standard support and 12 months of paid extended support, after which EKS upgrades the control plane on its own. For 1.31, extended support ends 26 November 2026. On OpenShift, 4.14 EUS Term 2 ends 31 October 2026, and if your clusters are still on OpenShift SDN they cannot pass 4.16.
- openThe AWS bill shows an extended support line for EKS clusters.
- recurringAn AWS Health notice with an end of standard support date came in. Nobody owns it.
- blockedEach upgrade breaks an ingress controller, a service mesh or an operator.
- openThe control plane got upgraded last time, the node groups didn't, and now they're on different minors.
The estate, before and after
Before: clusters drifting behind with unowned lifecycle notices
Nobody was assigned the lifecycle notices. Old Helm charts and lagging add-ons blocked upgrades, node groups fell behind their control planes, and on OpenShift the SDN capped how far clusters could go.
Read the diagram as text
- AWS Health notices → EKS on extended support: unowned date
- Helm charts pinned years ago → EKS on extended support: removed APIs
- Helm charts pinned years ago → OpenShift on OpenShift SDN: removed APIs
- Add-ons and operators → EKS on extended support: lagging support
- EKS on extended support → Node groups: version skew
After: declared versions, a staging rehearsal and a fixed cadence
Cluster versions live in Terraform or GitOps, and we check each change for removed APIs before it runs. Every upgrade gets a rehearsal on staging. Then the control plane goes first and node groups after, with disruption budgets protecting workloads.
Read the diagram as text
- Terraform and GitOps → Deprecated API scan: manifests
- Lifecycle calendar → Staging cluster: schedule
- Deprecated API scan → Staging cluster: fix list
- Staging cluster → EKS on standard support: rehearsed upgrade
- Staging cluster → OpenShift on an EUS path: rehearsed upgrade
- Terraform and GitOps → EKS on standard support: declared version
- EKS on standard support → Node groups: control plane first
- Node groups → Workloads: surge roll
How we run it, phase by phase.
5 phases take you from Clusters on old or extended-support minors to Supported EKS, AKS or OpenShift release. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Cluster and add-on inventory
We start with every cluster's control plane and node versions. Next to them go the managed and self-managed add-ons, operators, CNI, ingress, service mesh and admission controllers, each with the range of Kubernetes versions it supports.
- phase 02
Deprecated API and chart scan
Scan manifests, Helm releases and GitOps repos for APIs that disappear in the target minor. EKS upgrade insights, Pluto or kubent will catch most. The owner of each workload gets their own fix list.
- phase 03
Rehearse on non-production
Upgrade a staging cluster with the same add-ons first. On OpenShift, plan EUS-to-EUS paths with paused worker pools and migrate to OVN-Kubernetes before passing 4.16.
- phase 04
Control plane, then nodes
Control plane first, one minor at a time. Then add-ons. Then node groups, with surge settings and Pod disruption budgets so nothing goes down.
- phase 05
Cadence and automation
Cluster versions go into Terraform or GitOps, someone subscribes to the vendor lifecycle notices, and the next upgrade gets booked while this one is still running.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Control planes and node groups run the same minor
Each cluster was upgraded control plane first, then add-ons, then node groups. So no cluster is left running with a version skew.
- result 02
Removed APIs are found before an upgrade starts
We scan manifests, Helm releases and GitOps repos against the target minor ahead of each change. Workload owners get their fix lists before anything moves.
- result 03
Every upgrade is rehearsed on staging first
Non-production goes first, on a cluster with the same add-ons. Each cluster type has a runbook, with rollback steps.
- result 04
OpenShift has a clear path past 4.16
We moved the OpenShift SDN clusters to OVN-Kubernetes. EUS-to-EUS upgrades now run with worker pools paused.
- result 05
Versions are declared and scheduled
We put cluster versions in Terraform or GitOps. Vendor lifecycle notices go to a named owner. Each upgrade sits on a cadence calendar tied to vendor dates.
Risks we plan for
-
Removed APIs in old charts
Charts pinned years ago will break on install once an API is removed. That's why the scan covers every repo, plus the live objects in the cluster.
-
Add-ons that lag behind
The provider may support a new minor long before your self-managed CNI, CSI drivers, ingress controllers and operators do. In practice their release notes set the upgrade date.
-
Forced upgrades at end of support
Once extended support ends, EKS updates the control plane at a time it doesn't announce and leaves the nodes behind. Plan ahead and you won't end up running a skewed cluster.
-
Stateful workloads
Databases and queues on Kubernetes need disruption budgets, backups and a tested restore before node pools roll.
Where AI helps, and where it needs guardrails
EKS upgrade insights flag what blocks the next minor in a cluster, removed APIs for example. We have AI assistants read the release notes and draft fixes for deprecated manifests. Each fix still goes through review and a staging upgrade. An agent that reaches the cluster through an MCP server gets a read-only role by default, and anything that can change the cluster needs approval.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- inventory01
Cluster, add-on and operator version inventory
yours to keep - code02
Deprecated API report with an owner per workload
yours to keep - runbook03
Upgrade runbook per cluster type with rollback steps
yours to keep - tests04
Rehearsal results from a non-production cluster
yours to keep - plan05
Version cadence calendar tied to vendor lifecycle dates
yours to keep
Platforms and services on this move
Services involved
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01Can we skip minors on EKS?
No. An EKS control plane moves one minor per upgrade. Nodes are allowed to lag by up to three minors, though we keep them close. Even OpenShift EUS-to-EUS updates take the control plane through the odd minor in between.
02Is EKS extended support worth paying for?
As a short bridge, sometimes. It costs extra per cluster hour and ends after 12 months with an automatic control plane upgrade. We treat it as time to fix blockers, not a place to stay.
03How long does an upgrade take?
Usually the control plane part is quick. Most of the time is spent on add-on compatibility, API fixes and testing, and that scales with your workloads and third-party operators. We size it from the inventory.
04Can you take over cluster operations?
Yes. Either we keep running upgrades, add-on updates and capacity reviews, or your platform team takes over with our runbooks.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case study
Apache Airflow 2 to Airflow 3
Upgrading self-managed Apache Airflow 2, now past end of life, to Airflow 3, and fixing removed features, auth and scheduling changes before DAGs move.
read the case study517e8ebb - 01AWS: Understand the Kubernetes version lifecycle on EKSdocs.aws.amazon.com ↗
- 02AWS: EKS cluster insightsdocs.aws.amazon.com ↗
- 03Red Hat: OpenShift Container Platform 4 life cycleaccess.redhat.com ↗
- 04Red Hat: OpenShift 4.17 release notes (OpenShift SDN removed)docs.redhat.com ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it