Kubernetes 1.35: kubelet won't start on cgroup v1 nodes

Starting with Kubernetes 1.35, the kubelet failCgroupV1 setting defaults to true, so kubelets on cgroup v1 nodes refuse to start and the node stays NotReady; on control-plane nodes the API server and etcd static pods fail to return after a reboot. A single stat -fc %T /sys/fs/cgroup/ call, or kubectl debug without SSH, reveals whether a node uses cgroup v1 or v2.

• failCgroupV1 defaults to true starting with Kubernetes 1.35
• On cgroup v1 the kubelet won't start and the node stays NotReady
• Check with stat -fc %T /sys/fs/cgroup/ — cgroup2fs or tmpfs
• cgroup v1 is default on CentOS 7, RHEL 7/8, Ubuntu 18.04/20.04, Amazon Linux 2