Kubernetes 1.37 on EKS, AKS, and GKE: Upgrade Deadlines and Support Costs in 2026

📷 "Ask Me Anything: Kubernetes and the Container Cluster Infrastructure. Mike Barrett, Marc Curry, Clayton Coleman, Red Hat" by ghaff is licensed under CC BY-SA 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by-sa/2.0/.

Kubernetes 1.37 „Garhwal" has been available upstream since August 26, 2026 — but for most teams, the release date matters less than the moment their managed provider rolls out the version in production. That moment has arrived in October 2026: Amazon has released 1.37 on EKS, Microsoft is following suit with AKS, and Google is initially holding back with the Rapid Channel. At the same time, a far more urgent deadline is expiring: the end of standard support for Kubernetes 1.34 — anyone who hasn’t upgraded by then will pay six times the cluster price on EKS.

EKS, AKS, GKE: The status of Kubernetes 1.37

AWS released Kubernetes 1.37 for Amazon EKS and EKS Distro in early October 2026 — in all regions where EKS is available, including the GovCloud regions and Frankfurt. New clusters can be created directly with 1.37, and existing ones can be updated via the console, eksctl, or infrastructure-as-code. AWS highlights three innovations in the announcement: The Metrics API has reached General Availability with metrics.k8s.io/v1, Dynamic Resource Allocation (DRA) can now schedule devices such as GPUs via Taints and Tolerations, and the Horizontal Pod Autoscaler scales down to zero pods on demand with minReplicas: 0 for object or external metrics (beta, enabled by default).

Microsoft is close behind: On AKS, 1.37 has been in preview since September, with GA planned for October 2026 according to the version calendar. Google is holding back: According to the GKE release notes, 1.37 is only available in the Rapid Channel as of early October. This makes EKS the first of the big three for broad adoption of the new minor version.

The more urgent deadline: End of standard support for 1.34

The more important date for many cluster operators is not the 1.37 upgrade, but the end of support for 1.34. On EKS, standard support ends on December 2, 2026. After that, the cluster automatically switches to Extended Support, which is enabled by default. Instead of 0.10 USD, the cluster then costs 0.60 USD per hour; at 730 hours per month, that amounts to roughly 365 USD in additional costs per cluster. On AKS, 1.34 also ends in November 2026; with Long-Term Support (LTS) enabled, the version remains usable there until November 2027.

The version policies of the providers differ significantly. EKS guarantees 14 months of standard support per minor version, followed by 12 more months of Extended Support — currently four versions in standard (1.34 to 1.37), three in Extended Support. AKS follows a twelve-month policy for GA versions, with optional LTS as a one-year extension. Anyone operating multiple clouds in parallel should factor these calendars into upgrade planning from the start — they are now just as important as the feature decisions of the upstream project.

Upgrade practice: SELinux, version skew, and rollback

When jumping to 1.37, there are three things to consider from an operational perspective. First, the SELinux change: Pods that share a volume with different labels can get stuck in ContainerCreating after the upgrade; nodes without SELinux are not affected. 1.37 should therefore be tested in a non-production environment before the production rollout, ideally with an eye on SELinux-capable nodes. Second, version skew: The Kubernetes policy allows up to three minor versions of difference between the control plane and nodes, but the recommended approach is an identical state — node groups on EKS are not automatically updated with the control plane and must be upgraded separately. Third, rollback: An in-place upgrade on EKS can be reverted to the previous minor version within seven days; after the automatic upgrade at the end of Extended Support, this is no longer possible.

Upstream, 1.37 is one of the most extensive releases of recent times with 67 enhancements. Anyone operating a version beyond its end of support should be aware that the community stops publishing CVE patches after about a year — unpatched control planes then become a security risk without official remediation. This is exactly why providers automatically upgrade at the end of Extended Support, without prior notice.

Conclusion

October 2026 shows how strongly managed Kubernetes is now shaped by version policy: EKS and AKS are rolling out 1.37, GKE follows via the Rapid Channel — and in parallel, the clock is ticking for 1.34. For teams, this means: take the upgrade calendar of your own provider seriously as operational discipline, plan one minor jump per upgrade, and treat Extended Support only as an expensive postponement, not as a permanent state. The next round is coming as scheduled — the Kubernetes project releases a new minor version on average every four months, so 1.38 is expected for December 2026.

Sources

🌐 Machine-translated from the German original, editorially reviewed. 🤖 Written with AI assistance.