Kubernetes is about to make an infrastructural hard choice explicit: in v1.35 the kubelet will default failCgroupV1 to true, meaning a node still running cgroup v1 can fail kubelet startup unless operators take action. This is not a gentle deprecation — it’s a hard stop for legacy cgroup behavior that’s been simmering since cgroup v2 gained broad support and signals that cgroup v1 is on a maintenance-only path.
That should wake teams up. For years the migration to cgroup v2 has been a background task for kernel and distro maintainers; now upstream Kubernetes is making it an operational dependency. The cost of delay is simple: unbootable worker nodes or kubelets that refuse to come up after an otherwise routine control-plane upgrade.
Why this matters now
- cgroup v2 has been supported in Kubernetes for several releases and upstream signals indicate cgroup v1 is being deprioritized. The change flips the kubelet’s compatibility behavior so that the presence of a legacy cgroup layout can cause kubelet to fail fast (failCgroupV1=true).
- Container runtimes and low-level tooling have added cgroup v2 support in recent releases. That ecosystem momentum makes stricter enforcement reasonable — but it forces platform teams to catch up.
What breaks in practice
If you upgrade control-plane components or kubelet without addressing node cgroup layout you’ll see kubelets crash-loop or stop during bootstrap. The symptom is not “pods fail to schedule” — it’s the node itself not registering because kubelet refuses to run. That means no graceful node replacement; autoscaling and rolling updates can stall.
There are a few common failure modes I’ve seen in field reports:
- Distros booting with cgroup v1–only kernels (older cloud images or custom kernels).
- Hosts where systemd is configured with the unified cgroup hierarchy disabled.
- Container runtimes packaged without cgroup v2 enabled or using older runc/containerd bundles.
This is the right call
Yes, it’s blunt — and yes, it’s overdue. Letting clusters limp along on cgroup v1 while the ecosystem assumes v2 has invited fragile workarounds and ad‑hoc fixes. Making kubelet fail loud forces a predictable migration window and forces vendors to ship compatible runtime stacks instead of papering over differences in downstream scripts.
But it will bite teams who treated cgroup migration as an optional housekeeping task.
Concrete actions to take this week
- Audit nodes for cgroup version: inspect /sys/fs/cgroup to see whether the unified hierarchy is in use and check kernel boot args (systemd.unified_cgroup_hierarchy=1).
- Confirm kubelet configuration: the kubelet can be controlled via the --fail-cgroup-v1 flag or the corresponding KubeletConfiguration field (FailCgroupV1). If you absolutely must postpone migration you can flip this, but that’s a temporary reprieve, not a plan.
- Validate runtime stack: ensure your runc/containerd (or other CRI) versions on nodes support cgroup v2 and that the CRI is configured for the unified hierarchy.
- Test upgrades in a staging fleet that matches production images and kernels. Kubelet-in-place failures are easiest to catch in a controlled canary.
Operational context: observability and Helm ops
This isn’t happening in isolation. Observability and scheduling tooling is improving, so you can trace where jobs and workloads fail when node pools vanish because kubelet won’t start. Helm and chart migrations still matter: real-world migrations require sequencing traffic and state carefully, and improved visibility helps you catch fallout early.
If you skip this
Downtime or noisy rollbacks will follow. Upgrades that used to be low-risk will become incident tickets when nodes silently refuse to run kubelet. The sensible path is to treat the upcoming default as an enforcement date, not a suggestion.
Final word
The migration to cgroup v2 is now a hard operational requirement. Platform teams should stop treating it as an optional kernel tweak and make it part of their upgrade runway — audit kernels, test runtimes, and use the new scheduling and admission observability tools to catch fallout early. Teams that treat v1.35 like just another patch will be the ones paged at 2 a.m. this winter.