runc 1.6.0-rc.1 dropped on Oct 6, and it’s not just another runtime bump — it’s an immutable-style RC that lands at the exact moment Kubernetes is tightening its cgroup story. That timing matters: Kubernetes has been explicit that cgroup v2 is the recommended path since earlier releases, kubelet has added behavior to fail when only cgroup v1 is available, and the remaining cgroup v1 fallback is scheduled for removal in an upcoming minor release. If you run clusters on mixed runtime stacks, this release candidate plus the removal window will be the thing that forces real testing and hard choices.
runc 1.6.0-rc.1: what to watch
The v1.6.0-rc.1 release is the first release candidate for runc 1.6.0; the project indicated the final 1.6.0 would follow later in October. This RC continues the trend toward immutability and stricter surface compatibility in OCI runtimes (see the related pre-release coverage runc 1.6.0-rc.1 immutable pre-release). Practically, expect changes that matter to containerd and CRI integrations: behavioral adjustments around namespaces, resource accounting, and security-hardened defaults that were previously optional are being locked down. Those are precisely the kinds of changes that reveal themselves only under real workloads and with the exact kernel/cgroup mix you run in production.
Kubernetes’s cgroup v2 timeline: it’s getting real
Kubernetes has reiterated the migration path: cgroup v2 is the recommended path, cgroup v1 is deprecated, and the project is moving toward removing the last cgroup v1 compatibility fallbacks in a forthcoming minor release (targeted for v1.38). Translation: if any node in your fleet still expects cgroup v1 semantics, kubelet may refuse to manage pods or behave unpredictably during minor upgrades. There is no longer an open-ended grace period — this is a scheduled removal.
Why this collision matters
Runtimes and kubelet rely on the same kernel primitives. When the runtime tightens defaults (runc locking down previously opt-in behavior) while kubelet is moving the ground under resource accounting (cgroup v2 enforcement), you get failures that are painful to debug: OOM accounting mismatches, device plugin failures, and scheduling oddities for memory- or device-bound workloads. That’s not hypothetical; the interplay between a new runc, updated containerd, and kubelet’s cgroup handling is a common source of node-level breakage during upgrades.
Kubernetes v1.37 graduations — small text, big practical effects
The v1.37 release notes call out several graduations with operational impact that change kubelet and scheduler behavior at runtime: native metrics histograms and Memory QoS changes in particular can alter how memory is measured and enforced at pod granularity. Those graduations will surface previously latent issues in workloads with noisy memory patterns and change expectations for scheduling and observability.
Docker Desktop and ecosystem quiet
Docker Desktop 4.94.0 shipped in early October but its release notes were light; in the same short window there weren't major new releases from containerd, CRI-O, Helm, Podman, BuildKit, or the core cluster managers (kubeadm, k3s, kind, minikube). That relative quiet is a small mercy — fewer moving parts while runtime and cgroup changes land.
Take: this is overdue and purposely disruptive
Kubernetes and runc are forcing a migration that should have happened years ago. Keeping cgroup v1 around was a long-lived wart that encouraged brittle node configuration and custom hacks. Making the removal scheduled and shipping stricter runtime releases is the right call — but it will be disruptive. Platform teams that treat runtimes and node-level primitives as low-risk configuration will be surprised.
If you still have any lingering nodes or images that assume cgroup v1, or if your CI doesn’t validate the exact stacks you run in production, treat the next minor release cycle as the migration event. Expect to need updated containerd/runc combinations, kernel packages, and at least one round of real-world load testing to validate Memory QoS and histogram-driven metrics behave as you expect. By the time v1.38 lands, there will be fewer escape hatches than there were in 2024 — and that’s good for cluster stability, but it makes Q4 the migration quarter.