Kubernetes 1.35 will not start your cgroup v1 nodes

If the kubelet fails to start after a Kubernetes 1.35 upgrade, and the node runs cgroup v1, the cause is a changed default. Kubernetes 1.35 sets the kubelet option failCgroupV1 to true. On a cgroup v1 node the kubelet now refuses to start, and no fallback path exists. The immediate fix is to set failCgroupV1: false before you upgrade. The durable fix is a node image on cgroup v2, because the override is a stay of execution.

That distinction matters more than usual this release. Two other deprecations land on the same machines. Flip the flag now, defer the rest, and you rebuild the same node pool twice.

What changed in Kubernetes 1.35?

Kubernetes 1.35 treats cgroup v2 as the assumed state of a worker node. Kubernetes is the container orchestration system that schedules workloads across a cluster of Linux machines. Cgroups are the kernel feature that limits and accounts for the CPU and memory a container may consume. Version 2 replaced version 1 as the kernel's supported layout years ago, and current mainstream distributions boot with it.

Until this release the kubelet ran on either layout. In Kubernetes 1.35 the kubelet refuses to start by default on nodes booted with cgroup v1, according to SUSE's support note on the startup failure. The node does not degrade or run with reduced limits. It simply never joins the cluster.

The change is recorded in the project's 1.35 changelog, alongside two further changes that touch the same nodes. Kubernetes 1.35 is the final version supporting containerd 1.x, so containerd 2.0 or later becomes mandatory before 1.36. The --pod-infra-container-image kubelet flag has also been removed, which breaks custom node images that still pass it, as Amazon's EKS version notes record for custom AMI users.

How do I check whether my nodes run cgroup v1?

Run one command on the node and read the filesystem type of the cgroup mount:

stat -fc %T /sys/fs/cgroup

cgroup2fs means the node already runs cgroup v2, and the Kubernetes 1.35 default is harmless there. tmpfs means the node runs cgroup v1, and the kubelet will refuse to start.

Check every node pool rather than one sample node. The nodes still on cgroup v1 are usually the oldest, such as long-lived custom AMIs, pinned base images, and machines built from a distribution release that predates the cgroup v2 default. Those pools are also the least likely to have been rebuilt for any other reason.

The override, and why it expires

Set failCgroupV1 to false in the kubelet configuration, before the upgrade rather than after it:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failCgroupV1: false

On clusters holding kubelet settings in a ConfigMap, that means editing kube-system/kubelet-config and rolling the nodes. Managed providers expose the same setting through their own node configuration. Oracle documents the field for managed node pools in its OKE release notes for 1.35, so check the provider API rather than editing files on the instance.

Treat the override as a migration window, not a setting. It buys one release. The flag exists so clusters on older Linux images can complete an upgrade instead of skipping it. A node that needs the override in 1.35 is a node that needs a new operating system image.

Why this is a node rebuild, not a flag flip

The changes below land on the same worker nodes on overlapping schedules. Handled separately, they mean draining and replacing the same pool three times.

Change in Kubernetes 1.35	Status now	Deadline
cgroup v1 nodes	Kubelet refuses to start; failCgroupV1: false overrides	Override is temporary; move to cgroup v2
containerd 1.x	Supported, for the last release	containerd 2.0 or later before 1.36
IPVS mode in kube-proxy	Deprecated	Removal scheduled for 1.36
--pod-infra-container-image	Removed from the kubelet	Already breaking in 1.35

kube-proxy is the component that programs a node's routing rules so traffic reaches service endpoints. Its IPVS deprecation is the item most often missed, because it lives outside the kubelet. Sysdig's breakdown of the 1.35 security changes places the removal in 1.36, the same release that drops containerd 1.x. Clusters that chose IPVS for large service counts need an nftables or iptables plan on that timeline.

One more item belongs on the same rebuild. The Kubernetes community stopped maintaining the NGINX Ingress controller in March 2026, so no further releases, bug fixes or security updates are coming for it. That is not a 1.35 blocker. It is a cost you may as well absorb while the pool is already being replaced.

The upgrade order that avoids rebuilding twice

1. Inventory every node pool with stat -fc %T /sys/fs/cgroup, and record the containerd version beside each result.
2. Build one node image with cgroup v2 and containerd 2.0 or later, and drop --pod-infra-container-image from its kubelet arguments.
3. Move kube-proxy off IPVS mode first, on your current Kubernetes version, so the routing change stays isolated.
4. Roll the new image through the pools with an ordinary drain and replace, while the control plane still runs 1.34.
5. Upgrade the control plane, then the nodes, to Kubernetes 1.35, leaving failCgroupV1 at its default.
6. Keep the override in reserve for any pool that cannot be rebuilt in time, and give that pool an owner and a date.

Step three is the one teams skip. Changing the kube-proxy backend and the container runtime in a single maintenance window makes any regression twice as expensive to diagnose. Consider a service that intermittently drops connections afterwards. The cause could be routing, runtime or kernel, and you have no clean way to bisect it.

Should you upgrade to Kubernetes 1.35 now or wait?

Wait if any pool still reports tmpfs, and spend the time on the node image instead. Reaching 1.35 with an override in place gains nothing, because 1.36 asks the same question with fewer answers available.

Upgrade now if every pool already runs cgroup v2 and containerd 2.0. This release is then routine, and moving early clears the path to 1.36 while its removals are months away rather than weeks.

Managed Kubernetes changes the calculation, because the provider owns the clock. Oracle, Amazon and Alibaba have each started rolling 1.35 into their managed offerings, and each publishes its own support window. On a managed control plane the question is not whether to upgrade. It is whether your node images will be ready when the provider's deadline arrives.

Readers of our note that Node.js 26 turns Temporal on. Upgrade now or wait? will recognize the shape of this. A flipped default is easier to miss than a removed API, and it fails at start-up rather than at build time. The kernel-level questions raised in SCTPhantom gives root on Linux. Do you need to care? land in the same place: the node image is the unit of work either way.