Kubernetes 1.37 officially ships.
And if your first reaction is "cool, another dot release," I get it. We've all sat through enough of these to develop a healthy immunity to release-day hype. But this one's got a few things in it that are worth pausing for, plus one deprecation that's going to quietly break dashboards for teams still running ipvs mode.
π Here's exactly what's shipping, what's getting deprecated, and — since most of you reading this run EKS — when Amazon will actually let you touch it.
π The Basics: What's Actually Happening Tomorrow
Kubernetes v1.37 reaches General Availability on August 26, 2026. The release cycle kicked off back in May, hit Enhancements Freeze in mid-June, and cleared Code & Test Freeze in late July — the usual cadence.
The release tracker lists roughly 86 enhancements in scope, with 28 of those graduating to a new stage this cycle. Of those, 16 land in Stable. That's a fairly typical mid-cycle release — not a blockbuster like 1.34 (DRA going GA) or 1.36 (User Namespaces GA), but there are two or three items in here that deserve your attention regardless of cluster size.
π― What's Graduating to Stable
Metrics API finally goes GA
The metrics.k8s.io API — the thing quietly powering kubectl top and the Horizontal Pod Autoscaler — is graduating to Stable after almost nine years in Beta. Nine years. That's longer than some of you have been running Kubernetes at all.
π Practically, nothing changes for you today. Both v1 and v1beta1 stay usable during the transition, so there's no forced migration. But if you've been holding off on building tooling against this API because "it's still beta," that excuse is gone.
Device-level taints and tolerations for DRA graduate to GA
Dynamic Resource Allocation keeps maturing. This release stabilizes the ability to taint individual devices (think: a specific GPU on a shared node) and have pods tolerate or avoid them — the same mental model as node taints, just scoped down to hardware. If you're running GPU-dense nodes for AI/ML workloads, this is the kind of feature that turns "why did my training job land on a half-broken GPU" into a solvable problem instead of a mystery.
KYAML output for kubectl
A quieter one, but developers will notice it: kubectl gains a cleaner, more predictable YAML output format. If you've ever piped kubectl get -o yaml into a diff tool and gotten frustrated by inconsistent key ordering, this is aimed squarely at you.
π§ͺ What's Moving to Beta
Kubelet in User Namespace — "Rootless Mode"
This is the one I'd actually pay attention to if you care about node-level security. Right now, kubelet and friends run with root privileges on the host — which means a vulnerability in a node component can potentially escalate to full host compromise.
Rootless Mode lets kubelet run inside a Linux user namespace as an unprivileged host user while still behaving like root inside its own namespace. Same trick that made User Namespaces for pods valuable in 1.36, now applied to the node components themselves.
π It's Beta, not GA — don't flip this on for production tomorrow. But if you're building out a hardened node image or evaluating a zero-trust node architecture, start testing it now in a sandbox cluster.
π¬ What's New in Alpha
The alpha list is long this cycle — around 34 net-new enhancements — and the center of gravity is, unsurprisingly, Dynamic Resource Allocation. A few worth watching:
- Volume Health Monitor — resets to Alpha after a first attempt back in 2021 that didn't stick. It gives CSI drivers a proper machine-readable way to report storage-level faults (think: a stale NFS handle silently corrupting writes) instead of forcing you to cross-reference vendor dashboards after the fact.
- Per-container ulimits — finer-grained control over resource limits at the container level instead of node-wide defaults.
- NFTables userspace proxy for NodePort on localhost — continuing the broader kube-proxy migration off iptables.
- EnforcedRollingUpdate for StatefulSets — a new flag tightening rolling update guarantees for stateful workloads.
Alpha means exactly what it always means: interesting, disabled by default, and not something you run in production. But it tells you where the project is spending its energy — and this cycle, that's clearly GPU/AI infrastructure and storage reliability.
⚠️ Breaking Changes and Deprecations You Need to Plan For
This is the section people skip and then regret skipping. Three items:
1. kube-proxy's ipvs mode is now formally deprecated
If you're running mode: ipvs in your KubeProxyConfiguration, your kube-proxy will start logging deprecation warnings on startup after this release. Nothing breaks yet — the timeline is: disabled by default around v1.40, fully removed around v1.43. But start planning your migration to nftables mode now instead of scrambling in eighteen months.
Check what you're running with:
kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:'2. Static Pods can no longer reference Secrets or ConfigMaps
Static Pods were never supposed to read API resources directly — they're not created through the API server. A bug let some clusters get away with referencing Secrets or ConfigMaps via fields like configMapRef anyway. That bug is fixed in 1.37, and the feature gate that let you opt back into the old (broken) behavior is gone entirely.
π If you have any static pod manifests doing this — audit them before you upgrade, not after.
3. SELinux volume relabeling (SELinuxMount) graduates to GA and is on by default
Faster SELinux volume labeling now becomes the default mount behavior — mount -o context=<label> instead of recursively relabeling every file. Good for performance. But because a single mount can only carry one SELinux context, pods with different SELinux labels sharing the same volume on the same node may now fail to start where they previously coexisted.
This only bites you if SELinux enforcement is actually on. If you're not running SELinux-enforcing nodes, skip this one entirely.
𧡠The Slow Death of cgroup v1 Continues
Nothing new here, but worth repeating since it keeps tripping people up: since v1.35, failCgroupV1 has defaulted to true, meaning kubelet refuses to start on cgroup v1 nodes unless you explicitly override it. That override is still available in 1.37, but treat it as a countdown timer, not a permanent fix — features like In-Place Pod Resizing and Tiered Memory Protection require cgroup v2 outright, and cgroup v1 support is headed for full removal in a future release.
π So When Does EKS Actually Get This?
Here's the part that actually matters for most of you: Amazon EKS does not support Kubernetes 1.37 yet, and won't tomorrow either. EKS's current supported version is 1.36, which shipped in June 2026.
AWS has a consistent pattern of adding EKS support several weeks after each upstream Kubernetes GA:
| Kubernetes Version | Upstream GA | EKS Support Announced | Lag |
|---|---|---|---|
| 1.34 | Aug 27, 2025 | Oct 6, 2025 | ~6 weeks |
| 1.35 | Dec 17, 2025 | Jan 28, 2026 | ~6 weeks |
| 1.36 | Apr 22, 2026 | Jun 2, 2026 | ~6 weeks |
π Based on that pattern, expect Amazon EKS to announce 1.37 support sometime in early-to-mid October 2026. That's a projection based on historical cadence, not a confirmed AWS date — AWS hasn't published one yet, and I'll update this post the moment they do.
K8s 1.37 GA upstream] --> B[~4-6 weeks
AWS builds & validates EKS Distro] B --> C[Est. Early-Mid Oct 2026
EKS 1.37 support announced] C --> D[Console / eksctl / IaC
upgrade path opens]
π₯ CloudChef Take: What To Actually Do Right Now
You don't need to do anything to your EKS clusters today — 1.37 isn't an EKS option yet. But there are two things worth doing this week:
- Audit your kube-proxy mode. If you're on ipvs, you have time, but "time" is not "forever." Start a nftables migration plan now.
- Check your static pod manifests for any Secret/ConfigMap references. This is the kind of thing that passes silently in staging and then breaks a control plane node in production the day you upgrade.
Everything else — Rootless kubelet, Volume Health Monitor, the DRA device taints — is genuinely exciting, but it's Alpha/Beta territory. Test it in a scratch cluster if you're curious. Don't bet production on it yet.
π Continue Your CloudChef Journey
π References
- Kubernetes v1.37 Sneak Peek — Official Kubernetes Blog
- Kubernetes v1.37 Release Schedule — SIG Release
- Amazon EKS and EKS Distro now supports Kubernetes 1.36 — AWS
- Understand the Kubernetes version lifecycle on EKS — AWS Docs
π Final Thoughts
Kubernetes 1.37 isn't a release that changes how you operate clusters tomorrow morning. It's a release that changes what you should be planning for over the next two upgrade cycles — get ahead of the ipvs deprecation, clean up any static pod misuse, and keep an eye on Rootless Mode as it heads toward GA.
π And when AWS flips the switch on EKS 1.37 — likely October — you'll already know exactly what you're getting into.
No comments:
Post a Comment