Kubernetes 1.37 Garhwal: What's Actually Stable Now

Kubernetes 1.37, code-named Garhwal after the Himalayan region in Uttarakhand, shipped on August 26, 2026, with 67 enhancements attached to it. If you tried to read all 67, you’d burn an afternoon on things that don’t touch your cluster. Here’s the version that fits in your lunch break: what’s stable, what’s worth testing, and what to ignore until it matures.

What’s actually stable (the part that won’t change under you)

Sixteen enhancements graduated to stable in 1.37, and three are worth knowing about regardless of what your cluster does.

metrics.k8s.io is stable. This is the Metrics API behind kubectl top and the Horizontal Pod Autoscaler’s CPU and memory readings. It’s been reliable in practice for a long time, but formally sitting in beta meant it violated a “no beta APIs in production” policy for teams strict about that rule. If that was the only thing blocking a piece of autoscaling tooling, it isn’t anymore.

Pod certificates and Cluster Trust Bundles are stable. Pods can now request short-lived X.509 certificates and receive cluster-scoped trust anchors through a projected volume:

apiVersion: v1
kind: Pod
spec:
  containers:
    - name: app
      volumeMounts:
        - name: cert
          mountPath: /var/run/certs
  volumes:
    - name: cert
      projected:
        sources:
          - podCertificate:
              signerName: kubernetes.io/kube-apiserver-client
              keyType: ECDSAP256
              credentialBundlePath: cert.pem

That’s a meaningful shift for anyone who’s been running a sidecar or a separate cert-manager deployment purely to get short-lived, automatically-rotated mTLS certificates into pods. It doesn’t replace cert-manager for every use case, but for basic pod-to-pod mTLS, this closes a gap that used to require third-party tooling by default.

KYAML is stable. It’s a YAML dialect compatible with existing tooling that adds opinionated formatting rules to avoid the parsing ambiguities that have caused real incidents (the classic “Norway problem,” where an unquoted no gets parsed as boolean false). If you generate manifests programmatically, it’s worth a look, though most hand-written YAML doesn’t need to change.

What’s in beta and worth testing now

KEP-5343 makes nftables the default kube-proxy backend instead of iptables, and 1.37 starts logging a warning if you haven’t explicitly configured a proxy mode. iptables rule evaluation is linear and gets slower as your service count grows; nftables was designed to scale better under the same load. This is the item most likely to bite someone who upgrades without reading the changelog, because a default changing under you during a routine version bump is exactly the kind of surprise that turns into an on-call page. If you’ve never explicitly set --proxy-mode on your cluster, that’s worth finding out this week, on staging, not during your next production upgrade window.

Kubelet-in-UserNS (rootless kubelet) reaches beta after more than five years of development. It lets kubelet itself run as a non-root user on the host, which matters for organizations with strict host-hardening requirements that currently make an exception for the control-plane agent. Beta means feature-complete enough for a serious pilot on a non-critical cluster, not yet a fleet-wide rollout.

Native histogram support for Kubernetes metrics moves to beta, adding Prometheus Native Histogram support with dynamic exponential bucket boundaries. The practical benefit is roughly a 10x reduction in time series count per histogram, which is a real cost and cardinality win if you’re running Prometheus at scale and histograms are a meaningful chunk of your metrics volume.

What’s in alpha (know about it, don’t build on it yet)

Pod-level checkpoint and restore extends the Container Runtime Interface with CheckpointPod and RestorePod RPCs, aimed at fast pod migration and debugging workflows where you want to snapshot a running pod’s state. It’s early. Worth watching if you’re building tooling in that space, not something to depend on in a pipeline today.

What to actually do this week

Most teams get three useful things out of this release. First, if you rely on kubectl top or HPA in any automation that specifically avoids beta APIs, that constraint is gone. Second, check your kube-proxy mode configuration before your next upgrade, since a default shift is the one change here capable of causing an incident if it arrives unannounced. Third, if pod-level mTLS has been on your backlog behind “we’d need to stand up cert-manager for this,” the built-in pod certificate support is worth a prototype.

This follows the same pattern as Kubernetes 1.36 Haru a few months back: a handful of genuinely useful stable graduations buried in a long list of items that don’t apply to most clusters. Reading the stable list and skimming the rest is a reasonable way to spend fifteen minutes on a Kubernetes release; reading all 67 enhancements in detail rarely is. If your platform team doesn’t have a standing process for triaging releases like this one, that’s a smaller fix than it sounds, and it’s the kind of platform engineering work our infrastructure team helps clients build into a normal quarterly cadence instead of a one-off scramble.