Kubernetes 1.37 Garhwal: Two Defaults That Change Behavior Without You Asking

Kubernetes 1.37, named Garhwal, was released on August 26, 2026. It carries 67 enhancements: 16 graduated to stable, 23 reached beta, 27 landed as alpha, and one deprecation was recorded.

Release roundups will lead with the stable graduations, and some of them are genuinely good. This piece leads somewhere else, because two items in this release change how a cluster behaves without anyone changing a manifest, and one of them is a footgun with a plausible path to flooding your event pipeline. This covers the release shape, the event-rate change, what is happening to kube-proxy, the format change that improves daily life, what actually graduated, and how to sequence an upgrade. If containers themselves are new to you, start with our primer on what containers are.

What kubernetes 1.37 contains, in shape

The release announcement gives the distribution, and the distribution is the story before any individual feature is.

Twenty-seven alpha enhancements against sixteen stable is a forward-loaded release. Most of what is being written about this week is not something you can use in production yet. The sixteen stable graduations are the part that affects clusters now, and the single deprecation is the part that affects clusters later.

The event rate change that will not announce itself

This one is in the release’s own urgent upgrade notes and it deserves to be the first thing you check.

The kubelet configuration field eventRecordQPS controls how many events per second the kubelet will record. Previously, setting it to 0 meant "use the default," and the default was 50. As of this release, the changelog states plainly: "When eventRecordQPS in kubelet configuration file is set to 0, there will be no limit enforced."

Zero used to mean fifty. Zero now means unlimited.

If any node in your fleet has eventRecordQPS: 0 in its kubelet config, whether set deliberately years ago or inherited from a template nobody has read since, that node’s event rate limit is removed on upgrade. The failure mode is not a crash. It is a node under some unusual condition generating events without a ceiling, and whatever sits downstream of your events absorbing that. The changelog gives the fix directly: to preserve the old behavior, set the value to 50.

This is the class of change that static analysis will not catch, because the config is still valid and the value is still legal. Only the meaning moved.

kube-proxy is being steered off iptables, slowly

The single deprecation in this release is part of a longer arc, and 1.37 is the release where it starts talking to you.

IPVS mode for kube-proxy has been deprecated since v1.35, and Kubernetes’ own networking reference documents the proxy modes and how traffic is actually handled in each. This release adds a KubeProxyIPVS feature gate in preparation for eventual removal. The changelog is specific about where users should go: newer Linux kernels should migrate to nftables mode, which has been GA since 1.33, while older kernels stay on iptables, which remains the current default.

Separately, kube-proxy now warns when the proxy mode is not set explicitly. If you supply a KubeProxyConfiguration without a mode field, kubeadm defaults to iptables and 1.37 will issue a warning about it, because the default is expected to shift to nftables eventually.

Both halves point the same direction and the practical instruction is the same: set your proxy mode explicitly, now. Not because anything breaks in 1.37, but because an unset field whose default is scheduled to change is a decision being made for you at an upgrade you have not planned yet. Writing the value down converts a future surprise into a deliberate migration. Our overview of IT infrastructure components covers why explicit configuration beats inherited defaults generally.

KYAML is the quality-of-life win

The stable graduation most people will actually feel is KYAML, which addresses a problem every Kubernetes operator has hit and most have stopped noticing.

KYAML is a YAML dialect that stays compatible with existing tooling while applying an opinionated formatting approach: consistent brackets and quoting, structured output. Its purpose is avoiding the classic YAML pitfalls, the most famous of which is the Norway bug, where the unquoted country code NO parses as the boolean false.

That bug is funny once and expensive thereafter. A format that quotes consistently removes an entire category of configuration error that has nothing to do with Kubernetes and everything to do with YAML being more permissive than anyone wants. If you generate manifests programmatically, this is the item in the release worth adopting first, because it costs nothing and removes a failure mode.

The compatibility promise is the part that makes adoption easy. KYAML output is still YAML, so anything that already parses your manifests keeps working. You are not migrating to a new format, you are constraining how the existing one gets written.

What else graduated

Beyond KYAML, the changelog confirms several GA promotions worth knowing about.

The DRA graduation is the one with the longest tail. Scheduling GPUs and other specialized devices has been the weakest part of running AI workloads on Kubernetes, and DRA reaching GA for extended resources is a real step. Anyone sizing hardware for that kind of work should read it alongside our piece on hardware for AI agents.

The relaxed Service names change is small and pleasant. The restriction against leading digits has tripped people naming services after versions or numbered environments for years, and it is now gone.

Two beta items are worth watching even though they are not yet safe to depend on. Per Cloudsmith’s breakdown of the release, a CBOR serializer reaches beta with roughly 8x faster encoding and 2x faster decoding for custom resources, and native histogram metrics arrive claiming around a 10x reduction in time series storage overhead. Both are vendor-reported figures rather than independent measurements, so treat the multipliers as direction rather than specification. If either holds at half its claimed size, the effect on a large cluster’s monitoring bill is still real.

How to sequence the upgrade

Five steps, ordered by how much trouble each one prevents.

Grep your kubelet configs for eventRecordQPS before anything else. If any node has it set to 0, decide deliberately whether you want unlimited or 50. This takes minutes and is the only item here that can bite immediately.

Set mode explicitly in your kube-proxy configuration. Whatever you are running today, write it down. The warning in 1.37 is advance notice, and advance notice is worth acting on while it is cheap.

Inventory whether anything is on IPVS. If so, check kernel versions and plan the move to nftables. The feature gate arriving is the signal that the clock has started.

Do not build on the twenty-seven alpha features. They are off by default and subject to change. Reading about them is fine; planning around them is not.

Adopt KYAML where you generate manifests. Lowest cost, immediate benefit, no migration required.

Why the boring items matter more than the headline

There is a pattern worth naming, because it recurs in every release of every widely deployed system.

The features that get written about are the ones that add capability. The changes that actually cost operators time are the ones that alter the meaning of configuration that already exists. A new alpha API you have never used cannot hurt you. A field whose value silently changed meaning between versions is sitting in your cluster right now, valid, unremarked, and behaving differently than it did last week.

That is the reason to read urgent upgrade notes before feature summaries, and it generalizes past Kubernetes. We made the same argument about local model servers in local AI agent security, where the vulnerability came not from new code but from a wrapper quietly changing a default that a security control depended on. Defaults are where the surprises live.

Frequently Asked Questions