Kubernetes 1.37 just pulled the plug on a few long-lived compatibility crutches — and the thing that should wake platform teams up is the removal of cgroup v1 support. If your node images, container runtime, or custom tooling still assume cgroup v1, an in-place cluster upgrade to 1.37 is going to expose that technical debt fast.
The Garhwal release (v1.37) includes dozens of notable changes, with multiple features promoted across stability levels. The headline operational moves are the cleanups — legacy kube-dns artifacts removed where they still lingered, IPVS-based kube-proxy paths de-emphasized in favor of eBPF/iptables options, and official cgroup v1 support dropped. There were minor delays in some patches tied to automation and cadence issues, but the release itself focuses heavily on simplifying the node surface.
Why cgroup v1 matters now
cgroup v2 is not just a nicety; it changes how resource isolation, OOM accounting, and unified control groups behave across the stack. Dropping cgroup v1 support forces a straight line through the node stack: the distro kernel must expose the unified cgroup v2 hierarchy, the container runtime must fully support cgroup v2, and any glue code (CRI hooks, custom metrics collectors, lifecycle scripts) must be cgroup v2-aware.
This is the right call. cgroup v1 has been a maintenance and security liability for years: inconsistent accounting, fragmented controllers, and awkward interaction with systemd. Kubernetes moving the default ecosystem expectation to cgroup v2 reduces subtle bugs and unlocks future platform capabilities (better OOM handling, more reliable QoS tiers). But it's also an operational deadline: vendors and platform teams who treated node images as static are going to get paged.
IPVS removal — a nudge toward new dataplanes
The release also de-emphasizes IPVS-based kube-proxy mode. IPVS provided a high-performance backend, but it required kernel module support and added operational surface that some teams prefer to avoid. The practical effect is a push toward eBPF-based dataplanes or iptables/eBPF hybrids that reduce kernel-module lifecycle burden and enable richer observability.
If your cluster relies on IPVS for scale, you need a migration plan now. That may mean evaluating eBPF-capable CNIs, validating iptables fallbacks, or benchmarking combinations under worst-case service loads.
Other graduation and supply-chain moves
The release promotes several APIs and features toward greater stability, including advances in metrics and observability APIs. Parallel CNCF work — like increased attention to reproducible build and runtime pipelines and Cloud Native Buildpacks adoption — matters as teams run heavier AI/LLM workloads on Kubernetes and need auditable supply chains.
Operational checklist (brief)
- Validate node images: boot test nodes with unified cgroup v2 enabled and ensure systemd/kernel present the unified hierarchy.
- Verify your CRI: containerd, CRI-O, or other CRIs must be configured and tested with cgroup v2.
- Audit tooling: CI agents, in-node collectors, privileged DaemonSets, and any tooling that reads /sys/fs/cgroup must be updated.
- Reassess service dataplane: if you use IPVS, benchmark iptables and eBPF alternatives under production load.
This is not an optional cleanup. The release clears cruft that has complicated upgrades for years and creates a simpler, more secure baseline for the next generation of platform features (especially the sort of resource-heavy, latency-sensitive AI workloads CNCF is writing about). Managed Kubernetes providers will absorb much of the pain, but self-managed clusters and bespoke node images are on the hook.
Final thought
Kubernetes 1.37 is less about flashy features and more about hard maintenance: it forces the ecosystem to converge on modern kernels, runtimes, and dataplanes. If you've delayed updating node images or validating runtimes, treat this like a hard deadline — not a suggestion. The upside is real: fewer edge-case bugs and a cleaner platform to build LLMOps and other demanding workloads on. The downside is immediate: you will find surprises if you haven't tested node-level assumptions in the last 18 months.
For a quick look at the metrics graduation in v1.37, see Kubernetes: metrics.k8s.io API graduates to v1 stable.
Sources
- Kubernetes Blog - Kubernetes v1.37: Metrics API graduates to stable
- Kubernetes v1.37 Release Information
- Kubernetes Release Notes - August 2026 Latest Updates (patch delays and Go versions)
- The Register - Kubernetes v1.37 Garhwal cleans house (removes kube-dns, IPVS, cgroup v1)
- Last Week In Kubernetes Development (LWKD) - Week Ending August 23, 2026
- LWKD - Week Ending August 16, 2026 (RCs and Go versions)
- CNCF Blog - Your Kubernetes platform is ready for containers. Is it ready for AI?
- CNCF Blog - LLMOps and platform engineering: Who should own the AI pipeline?
- CNCF Announcements - Graduation of Cloud Native Buildpacks