Kubernetes v1.35 kubelet refuses to start on cgroup v1 nodes by default

The default flip puts the failure at kubelet startup. On v1.35 or later, under the default configuration, any remaining cgroup v1 node fails as the kubelet starts ^[5]. For clusters still below v1.35, the project tells operators to migrate every Linux node to cgroup v2 before upgrading, or to plan for the temporary override ^[4]. Clusters already on v1.35 should confirm that every Linux node runs cgroup v2, or that any override is there on purpose ^[5].

The project gave a long notice period before the flip. By v1.35, cgroup v2 support had been stable for ten minor releases ^[18], and cgroup v1 had spent four releases in maintenance mode ^[19]. Kubernetes has deprecated cgroup v1 ^[16].

A platform lead with a full roadmap could fairly say the override makes this next year's problem. For the kubelet, that holds for a while. Operators can set failCgroupV1: false in the kubelet configuration file, and the project describes the setting as temporary ^[2]. Its removal will follow the Kubernetes deprecation policy, with the remaining work tracked in KEP-5573 ^[2][3]. We think the override is defensible for a team that needs v1.35 this quarter for other reasons and already has a dated migration plan.

kubeadm fleets hit the check sooner. The project calls the v1.35 SystemVerification preflight check an earlier, stricter check, and it applies to init, join and upgrade alike ^[6]. The post does not say whether the kubelet override changes that preflight result.

Teams hoping the move would end page-cache evictions on I/O-heavy workloads will still need the existing workaround. That means equal memory requests and limits for containers doing intensive I/O, set after measuring an appropriate value ^[10]. The underlying kubelet behaviour is tracked as kubernetes/kubernetes#43916 ^[9].

We would not count Memory QoS as a reason to migrate this quarter. The feature was introduced as alpha in v1.22 and is still alpha in v1.36 ^[11], fourteen minor releases later ^[20]. The project's general advice is to keep alpha features out of production ^[13]. Its new tiered mode maps Guaranteed Pod memory requests to hard protection and Burstable requests to soft protection ^[15]. Teams that enable it in production are told to test the configuration and account for hard-reserved memory first ^[17]. The recommendation is kernel 5.9 or later. Below that, a known livelock can be set off by memory.high reclaim, and starting with v1.36 the kubelet writes a warning to its log if Memory QoS is turned on with one of those affected kernels ^[14].