When Will EKS, AKS, and GKE Actually Support Kubernetes 1.37?

Kubernetes 1.37 "Garhwal" shipped on August 26, 2026 — 67 enhancements, 16 of them graduating to stable. Twenty-seven days later, Amazon EKS has no 1.37 row in its release calendar at all. Not a delayed date, not a preview: the version simply does not exist on one of the most widely used managed Kubernetes services. If you run on EKS, every one of those 67 enhancements is a changelog entry you can read but cannot use.

This is not a bug in anyone's process. It is the managed Kubernetes bargain, working as designed: the cloud certifies on its own schedule, and you wait. The question is what the wait costs, what it buys you, and at what point owning the upgrade runbook yourself is the better trade. Here is the scoreboard, with dates.

The scoreboard: where 1.37 stands on each cloud​

As of September 22, 2026, the three managed control planes sit in three very different places:

The upstream anchors: 1.37.0 went GA on August 26, and the first patch release, 1.37.1, followed on September 11. That patch date matters more than it looks, because AWS has a documented policy of bringing new minors to EKS at the first patch release rather than the initial .0. EKS's own platform history corroborates it: the initial EKS release of 1.36 was 1.36.1, not 1.36.0.

This cycle's lag is not an anomaly either. It is the pattern. From the EKS release calendar:

Four consecutive releases, each landing on EKS five to six weeks after upstream. If 1.37 follows the pattern — and the 1.37.1 patch landing on September 11 keeps it on track — expect an EKS announcement in early to mid-October, roughly 40 days out.

AKS runs slower on paper but with a different shape: a September preview means you can test 1.37 workloads on Azure now, with full GA and its 12-month support clock starting in October. The prior cycle shows the pace: 1.34 went upstream in August 2025, hit AKS preview in October, and reached AKS GA in November — about three months end to end. GKE is the outlier in the other direction, typically serving a new minor within days to two weeks of upstream, then soaking it through the Rapid, Regular, Stable, and Extended channels so production clusters adopt at their own pace.

So the range is stark: same upstream release, same calendar date, and the gap between the fastest and slowest managed control plane is on the order of two months.

What the wait costs: three features you can't touch yet​

A version number is abstract. The cost of lag is concrete: specific features, GA'd upstream, that your clusters cannot run. Three of 1.37's beta headliners illustrate who pays.

HPA scale-to-zero (beta, enabled by default). After seven years as an alpha — it was first introduced back in v1.16 — the HorizontalPodAutoscaler can now scale a workload all the way to zero pods when idle and back up when demand returns. The whole change for most manifests is one line:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: queue-consumer
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: queue-consumer
  minReplicas: 0
  metrics:
    - type: External
      external:
        metric:
          name: queue_depth
        target:
          type: AverageValue
          averageValue: 10

One catch, and it is structural: with zero pods running there is no CPU or memory to measure, so scale-to-zero only works with object or external metrics — queue depth, requests per second, a cloud metric — never plain CPU utilization. Who pays for waiting: any team with spiky or idle-nightly workloads (queue consumers, batch inference, preview environments) that keeps paying for always-on pods because their managed control plane cannot schedule the zero state yet. On GPU-backed inference, idle time is the most expensive kind.

Rootless kubelet (beta). The node agent that has historically required root can now run inside a user namespace — KubeletInUserNamespace, with its own upstream feature blog walking through the graduation. This narrows the blast radius of a kubelet or container-escape vulnerability from "root on the host" to "an unprivileged UID," which is the kind of control auditors and compliance frameworks notice. Who pays for waiting: regulated teams and anyone whose threat model starts at the node boundary. They get to keep explaining the compensating controls for another quarter.

Prometheus native histograms (beta). 1.37 graduates native-histogram support to beta, moving high-resolution latency observation away from the precomputed-bucket classic histograms that force a tradeoff between cardinality and precision. Who pays for waiting: observability teams metering their Prometheus ingestion costs, who keep choosing between coarse buckets and expensive cardinality until their provider catches up.

And the stable graduations compound the point. The metrics.k8s.io API — the contract underneath kubectl top and every HPA — graduates to stable after close to nine years in beta, which finally gives cost-attribution and capacity tooling a locked API to build on. SELinuxMount goes GA enabled by default, replacing file-by-file volume relabeling with a single mount option. KYAML output graduates for kubectl. None of this is reachable on EKS or AKS GA today.

What the wait buys you: the honest counter-argument​

None of the above means managed lag is pure loss. The delay is also a soak period, and 1.37 is exactly the kind of release that benefits from one.

First, the patch release exists before most managed customers touch the minor. Whatever 1.37.1 fixed on September 11, EKS and AKS-GA customers will never experience as a day-one bug — AWS's first-patch policy guarantees it structurally. Second, the managed services wrap the upgrade in guardrails a self-hosted fleet has to build itself: EKS now supports rolling a cluster back to the previous minor within 7 days of an upgrade, a feature announced July 1 that directly de-risks the "upgrade broke prod" scenario. Third, the support windows are long once a version lands — 14 months of standard plus 12 months of extended support on EKS, 12 months from GA on AKS, staggered channels on GKE — so nobody is forced to upgrade on release day; the lag just shifts the window.

There is also a humility check for the self-hosting argument: opinionated installers have their own lag. kOps 1.37 had not been released at the time of writing — its release notes were still collecting changes toward a future cut. "Self-hosted" is not one thing; day-one access depends on which layer you own. The teams truly upgrading in the first week are on kubeadm, Cluster API, or hand-built control planes, not on every self-managed tool.

So the fair framing is not "managed is slow" but "managed trades calendar time for someone else's soak, rollback tooling, and support window." Whether that trade favors you depends on what is in the release — and 1.37, with scale-to-zero savings and rootless security posture sitting behind the wait, is a release where the cost side of the ledger is unusually legible.

The self-hosted trade: your runbook, your schedule​

The alternative to waiting is owning the upgrade yourself. A Cluster API-managed fleet, a kubeadm-built control plane, or any distribution that tracks upstream closely can move the week its runbook is ready — including the week of August 26. No certification queue, no preview-then-GA stagger, no 40-day pattern.

But "can move fast" is not "can move carelessly," and 1.37 punishes carelessness more than a typical minor. The price of skipping the queue is running this pre-upgrade checklist yourself, because 1.37 bundles several breaking-adjacent changes into one window:

• Audit kube-proxy mode. IPVS mode is now deprecated, nftables is the default backend for new installations, and full IPVS removal is targeted several releases out (roughly v1.43). It still works in 1.37 — but upgrading without inventorying which clusters use it starts a deprecation clock you are not watching.
• Stage-test SELinuxMount. It is GA and on by default, which changes mount behavior on every SELinux-enforcing node (RHEL, Fedora CoreOS derivatives). The new behavior is faster — one mount option instead of relabeling every file — and also the change most likely to break a workload that depended on the old labeling semantics. Test on staging, not prod.
• Remove static-pod credential refs. Static pods can no longer reference secrets or config maps. The removal is unconditional with no override flag, so every static manifest with a secretRef or configMapRef must migrate to another injection method before the kubelet upgrades.
• Check for cgroup v1 nodes. The 1.37 kubelet refuses to start on cgroup v1 hosts without an explicit override. Mixed fleets — the usual state of any fleet old enough to have history — need a node-image audit first.

None of these items is exotic. That is the point: the self-hosted trade is not heroics, it is a checklist, run on your schedule instead of Redmond's or Seattle's. A small platform team that can staff four audit items gets scale-to-zero and the rootless kubelet in September instead of October or November. A team that cannot staff them should gladly take the managed soak period — that is what it is for.

The decision rule​

Strip away the provider logos and the choice reduces to two questions:

1. Does your team need something in 1.37 this quarter? Idle-workload spend you could kill with scale-to-zero, a compliance finding rootless kubelets would close, an observability bill native histograms would cut — if the release has your feature, every week of lag has a price tag.
2. Can you staff the runbook? Four audit items, a staging cluster, and the discipline to run them before prod. If yes, the managed queue is pure cost with no benefit. If no, the queue is a service you are wisely consuming.

If the answers are yes/yes, self-host the control plane (or pick the managed channel that moves fastest) and stop donating two months per release to someone else's certification calendar. If either answer is no, stay where you are — but do it knowing the lag is a standing tax, roughly five to twelve weeks per minor, three minors a year, compounding across every feature you will ever want on day one.

The version-lag scoreboard will look different by the time 1.38 ships in December. The pattern will not: upstream moves, GKE follows in days, AKS in weeks-to-months, EKS at the first patch plus soak. Plan your roadmap against the pattern, not the announcement date.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Your platform, your upgrade schedule, your runbook. Star the repo on GitHub or deploy your first app today.