By Kubernetes v1.37 ships August 26, 2026. That is 44 days from today. It carries three breaking changes that will silently break your cluster during upgrade if you ignore them — and most teams will ignore them because all three were first announced in the v1.35 cycle, which already feels like ancient history. Here is what to check before you run that upgrade command.
The Three Breaking Changes
1. containerd 1.x Is Gone
v1.37 requires containerd 2.0 or later. The Kubernetes project aligned this removal with the end of containerd 1.7 support, so the timeline has been visible for over a year. That has not stopped teams from running containerd 1.7.x in production and calling it a day.
The failure mode is insidious: your control plane upgrades fine. Your worker nodes do not. kubelet refuses to start, nodes go NotReady, workloads get evicted or lost. The cluster appears healthy from the API server’s perspective until you try to schedule anything.
Steps to take now:
- Run
containerd --versionon every node. If you seev1.7.x, you have work to do. - Upgrade to containerd 1.7.21+ first, then run
ctr deprecations listto surface incompatibilities before jumping to 2.0. - If anything in your stack accesses the containerd socket directly — monitoring agents, custom tools — it must use the CRI v1 API. CRI v1alpha2 was removed in containerd 2.0.
- Any Docker Schema 1 images must move to Schema 2 or OCI format before you upgrade the runtime.
The good news: for most standard cluster setups, the containerd 1.7 to 2.0 migration requires no configuration changes. Run the deprecation check, fix what surfaces, and upgrade. GKE’s migration guide is the most thorough reference available even if you are not on GKE.
2. cgroup v1 Nodes Will Not Start
The FailCgroupV1 flag has defaulted to true since v1.35. In v1.37, nodes running cgroup v1 without an explicit failCgroupV1: false override in the kubelet config will refuse to start kubelet entirely.
This hits self-managed clusters hardest — bare metal, older VMs, anything still running on a CentOS 7-era base where cgroup v1 was the default. Managed services like GKE, EKS, and AKS are likely already handling this for you, but verify before trusting that assumption.
Check your current state:
# On each node — cgroup2fs means you're fine, tmpfs means you're not
stat -fc %T /sys/fs/cgroup/
# Query the kubelet metric across your cluster
kubectl get --raw /metrics | grep kubelet_cgroup_versionIf you are on cgroup v1, the path forward is an OS upgrade: Ubuntu 22.04+, RHEL 9+, and Debian 12+ all enable cgroup v2 by default. kubelet detects cgroup v2 automatically — no manual configuration needed once the OS is updated. If you cannot upgrade nodes before August 26, add failCgroupV1: false to your kubelet config as a temporary escape hatch. Just understand you are giving up Memory QoS, PSI metrics, and swap support until you migrate properly.
3. Deprecated Kubelet Flags Are Removed
KubeletCgroupDriverFromCRI has been GA since v1.36. In v1.37, the kubelet removes its legacy flag fallback behavior entirely — it relies on the CRI to report the cgroup driver, not on a manually set flag.
Audit your kubelet systemd units and startup scripts for any --cgroup-driver flags. Remove them. If you have configuration management (Ansible, Puppet, Terraform) that writes kubelet config files, update those templates now. Note that some originally-planned flag removals were deferred to v1.38 — do not assume inaction is safe without checking your specific flags against the v1.37 release notes as they finalize.
What Is Actually Worth Knowing
DRA Finally Does Something Useful for AI Workloads
Dynamic Resource Allocation went GA in v1.34. In v1.37, the focus is KEP-4815: Partitionable Devices, which entered alpha in v1.36. This lets you slice a single GPU — an A100, an H100 — into multiple logical units and allocate each independently to different Pods via ResourceClaim objects.
In practice: instead of dedicating an entire A100 to one inference pod, you run three to seven inference workloads on the same card using NVIDIA MIG partitions. Azure’s AKS team published a working configuration in March 2026. The NVIDIA MIG-aware scheduler is stable. The savings on inference serving costs are not theoretical.
The old nvidia.com/gpu: 1 extended resource pattern still works but does not give you this flexibility. The DeviceClass + ResourceClaim model is the path forward for anything beyond coarse GPU allocation.
etcd RangeStream Cuts Cluster CPU
etcd v3.7.0 shipped July 8 with RangeStream: large LIST results are now streamed in chunks rather than buffered server-side. v1.37 exposes this via the EtcdRangeStream feature gate. Clusters doing high-frequency LIST operations — controllers reconciling large namespaces, custom operators querying thousands of objects — will see meaningful etcd CPU reduction. It is opt-in and transparent to applications.
Pre-Flight Checklist
Run these against your v1.36 cluster before August 26:
- Verify containerd version on all nodes:
containerd --version - If on 1.7.x: upgrade to 1.7.21+, run
ctr deprecations list, then move to 2.0+ - Check CRI API usage in any tooling that accesses the containerd socket directly
- Audit Docker Schema 1 images:
docker manifest inspect <image> | grep schemaVersion - Confirm cgroup version on nodes:
stat -fc %T /sys/fs/cgroup/ - Query kubelet metrics for cgroup v1 nodes:
kubectl get --raw /metrics | grep kubelet_cgroup_version - Scan kubelet systemd units for deprecated
--cgroup-driverflags - Review kubelet config files for KubeletCgroupDriverFromCRI compatibility
Timeline
Code Freeze hits July 22. After that, v1.37 feature scope is locked. The six weeks between now and August 26 are exactly enough time to run pre-flight checks, remediate issues, and validate on a staging cluster. Teams that treat this as a later problem will be remediating in production while their users notice. The breaking changes in v1.37 are not subtle — they prevent nodes from starting. That is the kind of surprise that generates incident reports.
