Kubernetes v1.37 is scheduled to release on August 26, 2026. At the time of writing it has not shipped — the SIG Release team published its sneak peek on July 31, 2026, following the enhancements freeze, and that document is the only authoritative statement about the release so far.
That distinction matters more than it usually does, and it shapes how this piece is organized. Everything in the “confirmed” section below comes from the official sneak peek. Everything in the “provisional” section comes from pre-release tracking of the enhancements freeze, which is a good predictor and not a guarantee — features slip between freeze and release every cycle. If you are planning an upgrade window, plan against the first list and treat the second as likely.
The Deprecations Are the Part That Breaks You
New features are opt-in. Deprecations and removals are not, and they are what turns a routine minor-version bump into an incident.
Static Pods can no longer reference Secrets or ConfigMaps. The PreventStaticPodAPIReferences feature gate has been removed, which means the behavior is now unconditional. This is the item most likely to bite a cluster that has been running the same node bootstrap for years. Static pods are defined by files on the node and managed directly by the kubelet, so they tend to be the least-reviewed manifests in the fleet — kubeadm control-plane components, monitoring agents, custom node daemons written by someone who has since left. Any of those pulling configuration from a Secret or ConfigMap will fail to start after the upgrade.
Audit for this before you schedule anything else. Look in /etc/kubernetes/manifests (or wherever staticPodPath points on your nodes) for secretKeyRef, configMapKeyRef, and volume sources referencing Secrets or ConfigMaps. Anything you find needs its configuration inlined or delivered by another mechanism before the node runs 1.37.
kube-proxy’s ipvs mode is formally deprecated. KEP-5495 sets the timeline explicitly: ipvs mode is expected to be disabled by default in v1.40 and removed entirely in v1.43. The rationale is documented in KEP-3866.
This is not an emergency, and it is also not something to defer indefinitely. Three minor versions is roughly a year of Kubernetes release cadence. Teams running ipvs — usually because it was the recommended answer to iptables performance at scale several years ago — should be treating 1.37 as the signal to plan the migration rather than the signal to start worrying at 1.40. Pre-release tracking indicates nftables is on the path to becoming the default kube-proxy backend, which is where that migration is heading.
kubectl run --filename/-f is deprecated. Small in blast radius, annoying in practice, because it tends to be buried in scripts and runbooks rather than in reviewed manifests. Grep your automation.
cgroup v1 continues its exit. Since v1.35, failCgroupV1 has defaulted to true, meaning the kubelet will refuse to initialize on a node still using cgroup v1 unless explicitly overridden through KubeletConfiguration. That override is a temporary accommodation, not a supported long-term posture. If any node pool is still on cgroup v1 at this point, the upgrade to a v1.37 kubelet is not the problem to solve — the node OS image is.
What Pre-Release Tracking Says Is Graduating
Treat this section as provisional until the release notes land on August 26.
On the stable side, tracking of the enhancements freeze points to roughly 16 enhancements graduating, including KYAML output for kubectl, pod-level resources, and device-level taints and tolerations for Dynamic Resource Allocation. The DRA work is the one worth watching for anyone running GPU or specialized-accelerator workloads, because device-level taints give the scheduler a way to reason about a specific unhealthy or draining device rather than the whole node.
On the beta side, two items stand out. Kubelet-in-UserNS — rootless mode — is reported to reach beta, more than five years after its alpha debut in v1.22. That is a long arc, and it is the same direction of travel as the user-namespace work that landed in 1.36: reduce what “root” means inside a container relative to the host. Memory QoS with cgroups v2 is reported to reach beta and be enabled by default, which is the kind of change that alters memory-pressure behavior under load. If it lands as described, benchmark memory-sensitive workloads in a non-production pool before rolling it fleet-wide; “enabled by default” and “behaviorally neutral” are not the same thing.
The alpha list is large — reporting puts it around 22 new features, including a CompositePodGroup API, nftables as the default kube-proxy backend, topology support for volume snapshots, a volume health monitor, and a Recreate update strategy for StatefulSets. Alpha features are off by default and are not a reason to upgrade. They are useful as a read on where the project is going: several of these are about making the scheduler and storage layers aware of state they previously ignored.
A Practical Order of Operations
Before the release lands, three things are worth doing now, because they cost nothing and they are the ones that produce surprises later.
Audit static pod manifests across every node pool for Secret and ConfigMap references. This is the unconditional breaking change, it lives in the least-visible manifests you own, and it is the one that fails at kubelet start rather than at kubectl apply.
Determine your kube-proxy mode and, if it is ipvs, put the migration on a roadmap with a date attached to the v1.40 default-off milestone.
Confirm no node pool is running cgroup v1 behind the failCgroupV1 override.
After the release, read the actual release notes rather than pre-release summaries — including this one. The graduation lists above are drawn from tracking of the enhancements freeze, and the only version of that list worth upgrading against is the one published with the release on August 26. Then do what you would do for any minor version: canary one availability zone and one workload class, hold it for a week of real metrics, and only then move the rest of the fleet.
