The Kubernetes upgrade treadmill has a price tag now
Kubernetes releases a new minor version roughly three times a year. Each one is supported for a limited time. For years, falling behind was a quiet problem: old clusters kept running, and the upgrade got harder every quarter, but nothing showed up on the bill.
On EKS, it does now.
The numbers
Each Kubernetes version gets 14 months of standard support on EKS after it’s released there, then 12 months of extended support. During standard support, the control plane costs $0.10 per cluster per hour. During extended support it costs $0.60 per cluster per hour, six times as much.
For one cluster, that’s roughly $73 a month versus $438. A platform with 40 clusters across dev, staging, production and regions, all a version behind, pays about $14,600 a month more for the control planes alone. That’s before counting the engineering time to eventually do an upgrade that has become harder.
Why teams fall behind
Upgrades are rarely hard because of Kubernetes itself. They’re hard because of everything installed on the cluster:
- Removed APIs. Manifests and Helm charts using API versions that a new release removes.
- Add-ons with their own compatibility matrices: CNI, CoreDNS, ingress controllers, service meshes, autoscalers, policy engines.
- Snowflake clusters, each configured slightly differently, so each upgrade is a new investigation.
Make upgrades a routine, not a project
- Upgrade on a schedule, for example once or twice a year, rather than when support runs out. Small steps are cheaper than big ones.
- Check before you start. EKS upgrade insights flag deprecated API usage and other upgrade blockers in each cluster. Run them in CI against your manifests too, so new code doesn’t add new blockers.
- Treat add-ons as part of the cluster version. Pin add-on versions per Kubernetes version in code, and upgrade them together.
- Prefer replacing to patching. Create node groups on the new version and move workloads over, rather than upgrading nodes in place. For some teams, blue/green clusters (a new cluster, shift traffic, delete the old one) are simpler still.
- Reduce what you manage. EKS Auto Mode and managed add-ons move node and add-on upgrades to AWS. Fewer components you manage means fewer things that can block an upgrade.
Make the cost visible
Add a column to your cluster inventory: Kubernetes version, support status, and end-of-standard-support date. Put the extended support cost on the same report as the rest of the platform’s spend. When staying behind costs six times as much, scheduling the upgrade becomes much easier to justify.
The treadmill isn’t going away. What’s changed is that standing still on it now has a monthly price, and the price makes a good argument for keeping up.