Enforcing cgroup v2 in Kubernetes 1.35: Upgrade Path and Memory QoS Implications

cgroup v2 migration is now enforced in Kubernetes v1.35: the kubelet defaults to failCgroupV1: true, causing startup failure on nodes still using the legacy cgroup v1 hierarchy. The change tightens pre‑flight validation for kubeadm‑managed clusters and makes the newer memory QoS model available only on cgroup v2 nodes. Practitioners must verify the runtime environment before upgrading, or risk blocked cluster operations and loss of emerging resource‑control features.

Deprecation Timeline and Enforcement

Kubernetes has moved cgroup v1 into maintenance mode as of v1.31 and marked it deprecated. Starting with v1.35 the default kubelet configuration rejects cgroup v1 (failCgroupV1: true). Administrators can temporarily override this flag in the kubelet config file, but the override is expected to disappear according to the standard deprecation policy. For clusters created or upgraded with kubeadm, the SystemVerification pre‑flight check now returns an error when it detects cgroup v1 on a node running kubelet v1.35 or later; older kubelet versions only emit a warning. This early failure surface forces teams to address the runtime before proceeding with kubeadm init, kubeadm join, or kubeadm upgrade.

Resource Management Differences

cgroup v2 introduces a single, unified hierarchy and a more consistent interface for resource controllers. The most visible impact for Kubernetes is the availability of the Memory QoS feature set, which remains alpha in v1.36 but is limited to nodes that run cgroup v2. The feature relies on the v2 memory controller: memory.high implements throttling, while memory.min and memory.low provide hard and soft protection when the memoryReservationPolicy is set to TieredReservation. Guaranteeed Pods map to memory.min, Burstable Pods to memory.low, and BestEffort Pods receive no reservation. The default policy (memoryReservationPolicy: None) does not write these values, preserving existing behavior.

Operational Checklist for Migration

• Confirm that every Linux node reports a cgroup v2 mount (e.g., cat /proc/filesystems | grep cgroup2).
• If a node still uses v1, either upgrade the host OS or adjust the boot parameters to enable v2 before any Kubernetes upgrade.
• Review the kubelet configuration file; remove any temporary failCgroupV1: false overrides once all nodes are v2.
• Run kubeadm init --dry-run or kubeadm upgrade plan to surface the SystemVerification error early.
• Enable the MemoryQoS feature gate if tiered memory protection is required, and set memoryReservationPolicy accordingly.
• For I/O‑heavy workloads, continue to apply the documented workaround: align memory requests and limits to avoid false memory‑pressure signals caused by active_file accounting.

Related CloudNinjas coverage: Kubernetes.

What This Means For Practitioners

Teams must treat cgroup v2 adoption as a prerequisite for any Kubernetes upgrade beyond v1.35. The change eliminates a silent compatibility layer, turning mismatched node configurations into hard failures. It also opens the path to more granular memory protection, but only if the cluster is fully on cgroup v2 and the appropriate feature gates are enabled. Practitioners should audit node runtimes now, adjust automation to enforce v2, and incorporate the memory QoS settings into their pod‑resource design. Monitoring for upcoming removal of the temporary override flag will help avoid surprise disruptions in future releases.