If your fleet still boots nodes with cgroup v1 enabled, Kubernetes v1.35 will stop being forgiving: the planned default flip of failCgroupV1 to true makes the kubelet refuse to start on cgroup v1 systems. That's not a bug you can paper over with a restartit's a hard stop that will leave nodes offline until the OS/runtime stack supports cgroup v2.
This is the single most operationally disruptive change in the last week of upstream posts. cgroup v2 has been supported in Kubernetes in stages (starting around v1.25), but moving the fail switch into the default config is a blunt, overdue enforcement of a long-standing compatibility boundary. Platform teams that assumed distros or node images would silently carry the load are about to find out they were wrong.
Why this matters now
Kubelet behaviour here isn't subtle: with failCgroupV1=true the kubelet exits instead of attempting degraded behavior. That means node-level upgrades, images, and custom kernels that haven't enabled cgroup v2 will not just run poorly they won't run at all. The implications span packaged distributions, custom AMIs, and edge images for appliances.
A related piece of context: the OCI runtime and tooling ecosystem has been moving in this direction toosee recent runc and containerd work to align with cgroup v2. If your node stack uses older runtime builds you can hit mismatch and lifecycle problems during upgrades; it's not just a kubelet flag flip. For a deeper look at runtime-side changes, check recent runc and container runtime release notes and their migration guidance.
Kueue: Jobs stuck suspended, but no Pods to inspect
Separately, the Kubernetes docs published a practical debugging note (Oct 14) explaining why Jobs can remain suspended under Kueue even when there are no Pods or obvious application logs. Kueue suspends native Jobs during admission, turning work into Kueue Workload objects and waiting for admission decisions from a ClusterQueue/Queue evaluation. That indirection is powerful for fair-sharing and quota-aware batch scheduling, but it changes the mental model for debugging:
- The Job object can be suspended with no Pod created; kill the Pod-focused debugging loop and look at the Kueue control plane.
- Start by inspecting the Workload CR's status and conditions and the ClusterQueue's status. Events and conditions on the Workload are the primary signal of why admission hasn't happened.
- Controller logs (the kueue controller and the admission webhook) are the next stop; the admission path is where the matching and admission decisions occur.
The new Headlamp guidance is practical because it folds UI affordances into these steps: use Headlamp to follow a Workload, jump to related Queue/ClusterQueue resources, and view controller logs in-line. For teams that already use a dashboard for day-to-day ops, Headlamp's traceability will cut mean time to diagnosis significantlyespecially when admission failures are due to policy or resource-flavor mismatches rather than obvious controller crashes.
A blunt take: this is a good thingmostly
Setting failCgroupV1=true by default is the right call. cgroup v1 is an operational wart that has held back consistent behavior in resource accounting and QoS for years. It also simplifies testing matrices for SIG Node and the runtime ecosystem. But it's also the sort of change that will bite teams that treat upgrades as routine and node images as immutable.
If your rollout plan for the next year doesn't include validating node images and runtime versions for cgroup v2, you will have disruption. And if you treat Kueue as a transparent layer that only affects Pod creation, you will waste hours chasing non-existent Pods instead of reading Workload conditions.
A quick referee's note
Confidential Containers entering CNCF incubation (Oct 7) is an orthogonal but important governance signal: attestation-oriented isolation and confidential computing primitives are gaining mainstream stewardship. Expect more pressure to integrate node attestation and isolation patterns into platform blueprints, but don't conflate that with the immediate, concrete migration work cgroup v2 requires.
Final thought
Kubernetes is finally using defaults to force a cleaner platform surface. That will reduce long-term toil but increase short-term pain for teams that procrastinate upgrades. Treat v1.35 as a hard deadline: validate your node images, runtime versions, and Kueue admission paths now, because this time kubelet won't boot its way out of a misconfiguration.