Kubernetes 1.37, codename Garhwal, shipped August 26, 2026 after a 15-week cycle. 67 enhancements: 16 graduating to Stable, 23 to Beta, 27 new in Alpha, one deprecation track. Full release notes here.
Most of that is routine churn you’ll never touch directly. A smaller set of it changes how the control plane behaves under load, how AI/ML batch workloads get scheduled, and in one case will break pods on upgrade if you’re not paying attention. Here’s the part worth reading.
The control plane gets harder to knock over
Three separate features in this release attack the same failure window: cluster startup and recovery, when the control plane is doing the most work and has the least room to absorb mistakes.
Resilient watchcache initialization goes Stable. It’s one of the release team’s own four spotlight picks, and it earns it: kube-apiserver used to let watchcache init or re-init fire expensive List/Watch requests straight at etcd, which is exactly how a large cluster restart turns into a control-plane outage. Now those requests get routed through API Priority and Fairness with a bound on how much they can consume, and anything over that bound gets a flat 429 with a Retry-After header instead of piling onto etcd. Well-behaved clients back off; badly-behaved ones just get throttled instead of taking the API server down with them.
Manifest-based admission control configuration reaches Beta. Admission webhooks and CEL-based policies have always lived in the API, which means they depend on the API server and etcd both being up before they can do anything, and can’t defend their own configuration from being modified by someone with enough access. A new staticManifestsDir field lets you load webhooks and policies from files on disk instead. The project’s own description is worth quoting directly: “policies loaded this way are enforced from API server startup, keep working while etcd is unavailable, and can protect the API-based admission resources themselves from modification.” The files are watched for changes; a bad edit gets rejected and the previous config keeps running. This closes a bootstrap gap that’s been there since admission webhooks existed.
Pod certificates and Cluster Trust Bundles go Stable. This is first-class X.509 identity for workloads: an admin picks a signer name and runs a signer controller that watches PodCertificateRequest objects and issues and rotates certs, while maintaining the matching ClusterTrustBundle as the trust anchor. A workload opts in with a podCertificate projected volume, and can mount the ClusterTrustBundle as its own projected volume to get the anchor without a separate distribution mechanism. If you’ve been running a homegrown cert-issuance sidecar for workload identity, this is the API that was missing.
SELinuxMount and SELinuxChangePolicy also go Stable, both enabled by default, and this one comes with an actual gotcha. Volumes now get mounted with -o context=<label> instead of being recursively relabeled, but only on CSI drivers that opt in via .spec.seLinuxMount: true. The catch: a single mount can only carry one SELinux context. Two pods with different SELinux labels sharing a volume on the same node used to coexist fine under recursive relabeling. After this change, on an opted-in driver, the second one can fail to start. If that’s your setup, set .spec.seLinuxChangePolicy: Recursive on the pod to keep the old behavior — it’s not locked cluster-wide until 1.38, so you have one more release to catch this before it’s mandatory.
Scheduling gets a concept of “the whole workload”
The scheduler has always thought in pods. This release is the point where it starts thinking in groups of pods, which is what AI/ML training and batch jobs have needed for a while.
Base gang scheduling goes Beta: a PodGroup on top of the Workload API gives you all-or-nothing scheduling, so a group only gets placed once the cluster can fit every member, instead of half the group landing and the rest queuing forever. It also fixes a real livelock case where competing workloads kept interfering with each other without either one making progress.
Workload-aware preemption, Beta as well, is the natural extension: the scheduler now considers the whole PodGroup when deciding what to evict, instead of preempting individual pods that don’t actually free enough capacity for the workload waiting behind them.
The new CompositePodGroup API, Alpha, is the part built specifically for the messier AI/ML case: workloads structured as a hierarchy of groups, not a flat set of pods. The release notes frame it plainly — this is what enables multi-level gang scheduling, workload-aware preemption, and topology-aware scheduling for training jobs that don’t fit the flat model.
DRA picked up several pieces of the same story. Device taints and tolerations go Stable, so a driver can pull a specific device out of scheduling consideration, or an admin can taint a whole class of devices with a DeviceTaintRule. Extended resource requests via a DRA driver go Stable too, meaning something like abc.example/gpu: 3 can now be satisfied by a DeviceClass directly, without a separate device plugin. And ResourceClaim support for workloads reaches Beta, letting a ResourceClaimTemplate associate claims with an entire PodGroup instead of wiring up one claim per pod by hand.
Also worth knowing
- Memory QoS on cgroups v2 graduates to Beta, on by default. It uses
memory.min,memory.low, andmemory.highfor tiered protection: requests get shielded from reclaim, and anything overmemory.highgets throttled instead of OOM-killed outright. Tunable through kubelet’smemoryReservationPolicyandmemoryThrottlingFactorif the defaults are too aggressive for your workloads. - Pod-level checkpoint and restore lands in Alpha, the other spotlight feature. New CRI RPCs,
CheckpointPodandRestorePod, let kubelet checkpoint an entire pod and restore it later. It needs a container runtime that implements the new RPCs, so this isn’t something you can flip on with an arbitrary runtime yet. - The metrics.k8s.io API finally goes Stable after almost nine years in Beta. It’s the thing powering HPA and
kubectl top, and it took nearly a decade to graduate. - HorizontalPodAutoscaler scale to zero reaches Beta: for object or external metrics (not CPU/memory, which need running pods to measure), HPA can now scale a workload to zero replicas when idle and back up on demand. There’s a
ScaledToZerocondition so the controller can tell “I did this on purpose” from a manual scale-down. Named use cases: queue consumers, batch jobs, GPU workloads sitting idle between runs. - etcd RangeStream support and concurrent watch object decode (flipped on by default this release, Beta since 1.31) attack the same large-cluster startup cost from different angles: RangeStream streams etcd’s List responses in chunks instead of building the whole thing in memory first, and concurrent decode spreads per-event processing across a worker pool instead of one goroutine. The two together are benchmarked at roughly 55% faster watch-cache initialization over 150k pods.
- KYAML goes Stable: a safer, less ambiguous YAML subset for manifests, where every valid KYAML file is still ordinary YAML, so nothing you already have breaks.
kubectl get -o kyamlis stable alongside it.
What’s being phased out
kube-dns is deprecated, no new packages expected after 1.40 — CoreDNS has been the default since 1.13 anyway. kube-proxy’s ipvs mode is deprecated, disabled by default from 1.40 and removed by 1.43. kubectl run --filename/-f is on its way out. Static pods can no longer reference Secrets or ConfigMaps at all — this was always a bug, since static pods were never meant to read API resources, and the opt-out gate that let it slide has been removed entirely. And cgroup v1 support keeps shrinking: failCgroupV1 has defaulted to true since 1.35, the override is explicitly called a short-term fix, and features like Memory QoS only work on v2 to begin with.
None of these individually looks dramatic in a changelog. What ties them together is where they sit: watch cache resilience, manifest-based admission, and gang scheduling are all reactions to the same moment — a cluster doing a lot of work at once during startup, recovery, or a mass scheduling event, with less margin for the control plane to make a bad call. If anything you run fans out fast — a big batch job, an autoscaler event, a rolling restart across a large fleet — this release was built with exactly that window in mind.