Kubernetes v1.37 reached code freeze on July 22, 2026, which means the feature list stops moving and the upgrade planning starts. The release is due on August 26, and two of its changes are hard requirements rather than opt in features. The kubelet now needs containerd 2.0 or later, because containerd 1.x support and the old CRI v1alpha2 API are gone. Nodes still running cgroup v1 will refuse to start the kubelet unless you explicitly set failCgroupV1 to false. On top of that, Dynamic Resource Allocation moves further along, and etcd RangeStream lands to make large list calls cheaper. This is the point to test, not the point to be surprised in production.
The short answer
Kubernetes v1.37 reached code freeze on July 22, 2026, with general availability due on August 26. The two changes that will reach every operator are hard requirements: the kubelet needs containerd 2.0 or later, and cgroup v2 is effectively mandatory because the FailCgroupV1 gate defaults to true. Dynamic Resource Allocation advances, with Device Taints and Tolerations reaching general availability, and etcd RangeStream lands behind a feature gate to make large list operations cheaper. None of this is meant to be discovered on a live node, so test the release candidates first.
Most code freezes are a quiet administrative milestone. This one deserves a calendar reminder, because Kubernetes v1.37 turns two things that were recommendations into requirements, and both live at the node level where a bad assumption becomes a NotReady status.
The two changes that are not optional
Start with the runtime. Kubernetes v1.37 drops support for containerd 1.x, and the old CRI v1alpha2 API is removed. If a node still runs a 1.x containerd series, the kubelet will not negotiate with it the way v1.37 expects. The fix is boring and that is the point: check every node with containerd --version, and move the runtime to 2.0 or later before you touch the control plane.
The second change is cgroups. cgroup v2 is now the assumed world. A node still on cgroup v1 will fail to start the kubelet unless you explicitly set failCgroupV1 to false, because the FailCgroupV1 flag defaults to true in this release. The legacy --cgroup-driver flag fallback has also been removed, so the kubelet trusts the cgroup driver that the CRI reports and nothing else. Confirm each node with stat -fc %T /sys/fs/cgroup/, which should say cgroup2fs. Any host still presenting the old hierarchy needs a reconfiguration, not a hope.
Dynamic Resource Allocation keeps growing up
The interesting feature work is in Dynamic Resource Allocation, the framework that lets Kubernetes schedule specialised hardware with the same care it gives to CPU and memory. In v1.37, Device Taints and Tolerations reach general availability through the resource.k8s.io/v1 API, which gives operators a first class way to cordon a failing accelerator so the scheduler stops placing claims on it.
Partitionable Devices remain in alpha. That is the line to watch if you run inference, because it is the path toward carving one physical GPU into several schedulable slices for multi tenant workloads. It is not production ready yet, but the direction is clear, and it is worth exercising in a test cluster now so the eventual graduation is not a cold start.
etcd gets cheaper large lists
There is a quieter win at the storage layer. etcd v3.7.0 shipped on July 8 with a feature called RangeStream, and v1.37 exposes it through the EtcdRangeStream feature gate. The mechanic is simple and useful: large list operations stream their results in chunks rather than buffering the whole response server side. For clusters that issue frequent, large list and watch calls, and anyone running a busy control plane knows they exist, that translates directly into lower etcd CPU. It is off behind a gate for now, which is the right posture for a change this close to the datastore, but it is one to benchmark deliberately once you are on the release.
The upgrade is a checklist, so use one
The healthiest way to treat v1.37 is as an operations task with three concrete gates. Confirm containerd 2.0 or later on every node. Confirm cgroup v2 on every node. Run ctr deprecations list to catch runtime level incompatibilities before the scheduler does. Then take a staging cluster, point it at a v1.37 release candidate, and run your actual workloads through it, with particular attention to device plugins, GPU scheduling and any component that leans on high frequency list traffic.
Code freeze on July 22 means the surprises are already written down. General availability on August 26 means you have about five weeks to read them. Spending an afternoon in staging now is a lot cheaper than spending an evening on a node that will not rejoin the cluster.
Sources and further reading
- Kubernetes v1.37 Release Information
- Kubernetes v1.37 release schedule and team
- Kubernetes releases overview
Frequently asked questions
When does Kubernetes v1.37 actually ship?
Code freeze landed on July 22, 2026 (anywhere on Earth), which is July 23 at 12:00 UTC. From that point the v1.37 feature scope is locked and the cycle turns to stabilisation. General availability is scheduled for August 26, 2026. The gap between those two dates is exactly the window to run the release candidates against your own clusters, because everything that will be in the final build is already in the tree.
Why does v1.37 require containerd 2.0?
Kubernetes v1.37 drops support for containerd 1.x, and the old CRI v1alpha2 runtime API was removed. If your nodes still run a containerd 1.x series, the kubelet will not talk to the runtime the way it expects. Check every node with containerd --version before you upgrade, and roll the runtime forward first. This is the kind of prerequisite that is trivial to fix in staging and painful to discover on a node that just went NotReady.
What changes with cgroup v2 in this release?
cgroup v2 becomes the assumed default. Nodes running cgroup v1 will fail to start the kubelet unless failCgroupV1 is explicitly set to false, because the FailCgroupV1 flag now defaults to true. The legacy --cgroup-driver flag fallback is also gone, so the kubelet relies entirely on the cgroup driver reported by the CRI. Verify each node with stat -fc %T /sys/fs/cgroup/, which should report cgroup2fs, and plan a node reconfiguration for any host still on the old hierarchy.
What is new for Dynamic Resource Allocation and etcd?
Dynamic Resource Allocation keeps maturing. Device Taints and Tolerations reached general availability through the resource.k8s.io/v1 API, and Partitionable Devices continue in alpha, which is the path toward slicing a single GPU across multi tenant inference workloads. Separately, etcd v3.7.0 shipped on July 8 with RangeStream, and v1.37 exposes it through the EtcdRangeStream feature gate. Large list operations now stream in chunks instead of buffering server side, which lowers etcd CPU for clusters that issue frequent, large list calls.
What should I do before upgrading to v1.37?
Three checks cover most of the risk. Confirm containerd 2.0 or later on every node with containerd --version. Confirm cgroup v2 on every node with stat -fc %T /sys/fs/cgroup/. Run ctr deprecations list to surface runtime level incompatibilities before they bite. Then point a staging cluster at a v1.37 release candidate and exercise your real workloads, especially anything that depends on device plugins, GPU scheduling or high frequency list and watch traffic.