runc 1.6.0-rc.1 dropped in early October and it isn't a routine bump — it's a clear signal that container runtimes are formally aligning on cgroup v2 and they're doing it on a hard timeline. The RC is immutable, the project expects the final 1.6.0 in late October 2026, and that timeline matters because Kubernetes v1.37 is shipping complementary changes (node swap considerations, PVC last-used tracking in beta, and native histograms graduating to beta and enabled by default). If your cluster image/boot process, kubelet flags, or CI don't exercise cgroup v2, you need to stop postponing those tests now.
runc's 1.6.0-rc.1 is explicitly about compatibility and expectations around cgroup v2. The release candidate being immutable is important: it means the runtime API surface going into 1.6.0 is effectively frozen and downstream packagers (Docker, containerd integrations, OS distributions) will treat that RC as the platform contract. Vendors and distributions typically pick up runc changes quickly, so if you manage custom node images or an immutable OS image pipeline, treat this RC as a near-term compatibility bell.
Why this matters for Kubernetes operators
Kubernetes itself is moving: upcoming releases include features that change long-standing operational assumptions. Node swap handling is back on the table (with implications for eviction and QoS accounting), PVC last-used tracking is moving toward beta and offers clearer lifecycle signals for storage, and native histogram support advancing to beta affects how components expose metrics. Combine those with an enforced cgroup v2 runtime and you get a stack where kernel config, runtime flags, and kubelet behavior interact in ways you may not see if you only test on cgroup v1.
Concretely: cgroup v2 changes how memory and CPU pressure are observed and enforced. Scheduler behavior, eviction thresholds, OOM handling, and tools that read /sys/fs/cgroup will see different semantics. The unified hierarchy and some in-kernel pressure metrics alter resource accounting for bursty workloads. If your CI only spins up a single-node VM with cgroup v1, you won't see those differences until a live upgrade — the result can be sporadic evictions, unexpected CPU throttling, or metrics that no longer match prior baselines.
Storage and metrics implications
PVC last-used tracking (moving toward beta) is a small operational win — clusters can annotate PVCs with last access time, which helps reclaim policies and housekeeping tools make better decisions. Likewise, changes around observability tooling matter: native histogram support advancing to beta means histograms may appear where summaries used to be. Histograms and summaries are not interchangeable; pipelines and dashboards that assume one will need adjustment, and SLO calculations and percentile-based alerts may require recalculation during upgrades.
What to do this week
- Add cgroup v2 runs to your CI matrix. Boot node images with cgroup v2, run kubelet and the full e2e flows that exercise eviction and bursty load. If you're using distro images that pin runtimes, check which runc they include and whether the RC will be promoted into those images.
- Validate disk/volume lifecycle tooling against PVC last-used annotations — cleaners and reclaim controllers need tests that cover annotated-but-unused volumes.
- Audit observability: confirm your metrics consumers can handle native histograms and that percentile alerts are computed from histogram buckets, not summaries.
If you want the short, blunt take: this is overdue and it's the right direction. The container ecosystem needed a single, sane cgroup story. But it's going to bite teams who treated the runtime as plumbing they could ignore. Treat runc 1.6.0-rc.1 as a soft freeze on assumptions and as your cue to make cgroup v2 part of your standard upgrade playbook.
For a deeper look at the RC's specifics and Kubernetes-side implications, see our earlier write-up on the runc RC and platform impacts: runc 1.6.0-rc.1: cgroup v2 alignment and immutable RC 1 implications for Kubernetes platforms.
Expect a busy October: runtimes and cluster features are converging, and the teams that run reproducible, cgroup-v2-capable CI will be the ones who sleep through the upgrades.