Kubernetes 1.37 reaches EKS, AKS and GKE while 1.34 support deadlines loom

Kubernetes 1.37 arrives on the managed platforms

The Kubernetes project shipped version 1.37, codenamed Garhwal, upstream on 26 August 2026, but for teams on managed clusters the release only counts once their provider turns it on. According to a dev.to analysis, that switch has now been flipped. AWS made 1.37 generally available on Amazon EKS and the EKS Distro in early October, covering every region where EKS runs, including GovCloud and Frankfurt. New clusters can be bootstrapped directly on 1.37, and existing ones upgraded through the console, eksctl, or infrastructure-as-code pipelines.

Microsoft is a step behind: AKS has carried 1.37 in preview since September, with general availability pencilled in for October according to the service's version calendar. Google is more cautious still. The GKE release notes, as cited by dev.to, show 1.37 restricted to the Rapid Channel as of early October, which leaves EKS the first of the three major providers to offer the version for mainstream production use.

What the new version brings

Three changes stand out in AWS's announcement, per dev.to. The Metrics API has reached general availability under metrics.k8s.io/v1. Dynamic Resource Allocation can now place hardware such as GPUs using Taints and Tolerations. And the Horizontal Pod Autoscaler can scale a workload all the way down to zero pods by setting minReplicas to 0 with object or external metrics, a beta capability that ships enabled by default. Upstream, dev.to counts 67 enhancements in 1.37, making it one of the heavier releases of recent cycles.

The nearer deadline is 1.34

For many operators the 1.37 rollout matters less than the expiry of standard support for 1.34. On EKS that window closes on 2 December 2026. Clusters still on 1.34 at that point slide automatically into Extended Support, which is enabled by default and priced at 0.60 USD per hour instead of 0.10 USD. At 730 hours a month, dev.to calculates roughly 365 USD in additional monthly cost per cluster.

AKS drops 1.34 in November 2026, though its optional Long-Term Support keeps the version usable until November 2027. The support models diverge noticeably between providers. EKS promises 14 months of standard support per minor version plus 12 further months of Extended Support, leaving four versions currently in standard (1.34 through 1.37) and three in Extended. AKS works on a 12-month cycle for GA versions, with LTS available as a single one-year extension.

Practical upgrade notes

dev.to flags three operational issues to check before moving to 1.37. The first is SELinux: pods that share a volume while carrying different labels can get stuck in ContainerCreating after the upgrade, whereas nodes without SELinux are unaffected, which is a reason to rehearse the upgrade on SELinux-capable nodes outside production first. The second is version skew: Kubernetes tolerates up to three minor versions between control plane and nodes, but matching versions are the safer target, and EKS node groups do not follow the control plane automatically. The third is rollback: an in-place EKS upgrade can be reverted to the previous minor version within seven days, whereas the forced upgrade at the end of Extended Support offers no way back.

There is also a security dimension. The community stops publishing CVE patches for a version after roughly a year, so a control plane left past its support window has no official remediation path. That is why providers ultimately upgrade clusters themselves at the end of Extended Support, without giving notice.

Why it matters

Version policy has become as decisive for managed Kubernetes as the features themselves. A team that misses the 2 December cutoff on EKS will not lose its clusters, but it will pay six times the usual hourly rate for standing still, and the upstream cadence of one minor release roughly every four months means 1.38 is expected as soon as December 2026. Operators running multiple clouds face three different support calendars at once. The practical takeaway from dev.to is straightforward: plan one minor-version jump at a time, treat Extended Support as an expensive deferral rather than a resting place, and let the provider's upgrade calendar shape operations as much as the upstream roadmap does.