Kubernetes outlines cgroup v1 upgrade risks and planned v1.38 removal

Kubernetes’ guidance published October 6, 2026 highlights an upgrade hazard for clusters still using cgroup v1: under defaults introduced in v1.35, their kubelets will not start. The post says the temporary cgroup v1 fallback remains supported in v1.36 and is scheduled for removal in v1.38. That makes it a migration bridge, not a long-term configuration choice. See the Kubernetes migration guidance.

Check both kubelet startup and kubeadm preflight

Starting with Kubernetes v1.35, failCgroupV1 defaults to true. Administrators can temporarily set failCgroupV1: false in the kubelet configuration to allow startup on a cgroup v1 node.

For kubeadm-managed clusters, there is also a preflight check to account for. The guidance says SystemVerification reports an error during kubeadm init, kubeadm join and kubeadm upgrade when it detects cgroup v1 with kubelet v1.35 or later. With an older kubelet, the check remains a warning. Review this check separately from the kubelet override when planning an upgrade. Both behaviors are described in the post’s deprecation section.

Verify the node platform before rollout

Support for cgroup v2 has been stable since Kubernetes v1.25. The documented prerequisites include:

• Linux nodes with cgroup v2 enabled in the operating system.
• Linux kernel 5.8 or later.
• A container runtime that supports cgroup v2.
• Matching kubelet and container-runtime cgroup drivers.

The post gives stat -fc %T /sys/fs/cgroup/ as a check for the active hierarchy: cgroup2fs indicates cgroup v2. It also advises updating software that reads the cgroup filesystem directly.

The practical implication is to treat migration as a node-platform change rather than only a kubelet configuration edit. Inventory node images, confirm the active hierarchy and driver alignment, and check monitoring and application dependencies before a staged rollout.

Validate memory-failure behavior

Include multi-process containers in migration testing. On cgroup v2 nodes, the kubelet defaults singleProcessOOMKill to false and sets memory.oom.group for each container cgroup. The resulting OOM behavior kills processes together within that container—not across the whole Pod—according to the container-aware OOM section.

Keep memory-pressure eviction checks in the validation plan too. The same guidance warns that kubelet treats active_file memory as not reclaimable; a large page cache can therefore contribute to memory pressure and Pod evictions for I/O-intensive workloads. Successful node startup should be the beginning of validation, not its only acceptance criterion.