Kubernetes cgroup v1 deprecated: the 1.35 check that stops EKS

With Kubernetes cgroup v1 deprecated since v1.35, the kubelet's failCgroupV1 setting now defaults to true, so a node still on cgroup v1 fails at kubelet startup. On Amazon EKS the stock AL2023 and Bottlerocket AMIs already run cgroup v2. The nodes that break are the ones someone customised, and you want to find them before EKS 1.34 leaves standard support on 2 December 2026.

By the end of this post you will know which EKS node types are exposed, how to check a node in one command, what the failCgroupV1: false override actually buys, and which workloads misbehave once a node moves to cgroup v2.

Milestone	Version or date	Source
cgroup v2 support stable	Kubernetes v1.25	Kubernetes blog
cgroup v1 moved to maintenance mode	Kubernetes v1.31	Kubernetes blog
failCgroupV1 defaults to true	Kubernetes v1.35	Kubernetes blog
Override still available	Kubernetes v1.37	v1.37 sneak peek
Removal of cgroup v1 support	No earlier than v1.38	KEP-5573
EKS 1.34 end of standard support	2 December 2026	AWS EKS calendar
EKS 1.35 end of standard support	27 March 2027	AWS EKS calendar

Kubernetes cgroup v1 deprecated, not removed: the sources disagree on wording

AWS's EKS 1.35 release notes head the change "Cgroup v1 Support Removed", then say in the next sentence that Kubernetes 1.35 deprecates cgroup v1 support. The second sentence is the accurate one. Upstream, the About cgroup v2 page marks cgroup v1 as deprecated since v1.35, with removal to follow the deprecation policy.

The removal date is where the primary sources drift. KEP-5573 sets no release and says removal will be done no earlier than 1.38. The 6 October 2026 Kubernetes blog post says the cgroup v1 fallback is scheduled for removal in v1.38, while the v1.37 sneak peek only says removal is planned for a future release. Plan as though 1.38 is the last version where the escape hatch might exist, not a version where it is guaranteed.

For an EKS team on 1.34 this matters because the upgrade you are making now is the one that flips the default. The cost of not upgrading is covered in our post on the EKS 1.34 end of support price jump; this post is about what stops the upgrade from working.

Do EKS node AMIs use cgroup v2? Mostly, with three exceptions

The EKS-optimized AL2023 and Bottlerocket AMIs use cgroup v2 by default, according to the EKS 1.35 release notes. Amazon Linux 2 is the cgroup v1 platform, and AWS's AL2 transition FAQ says 1.32 is the last Kubernetes version for which EKS released AL2 AMIs. If your node groups run 1.33 or 1.34 on stock AMIs, they are almost certainly already on cgroup v2.

Node type	cgroup version	Risk on 1.35
EKS AL2023 AMI, untouched	v2 by default	None from this change
EKS AL2023 AMI switched to v1 by hand	v1	Kubelet fails to start
EKS Bottlerocket AMI	v2 by default	None; the 1.35 image also sets failCgroupV1: false
Custom AMI built on Amazon Linux 2	v1	Kubelet fails to start
EKS Fargate	v1, per AWS	Managed by AWS; v2-only features unavailable

The second row is the trap. AWS's own AL2 FAQ offers re-enabling cgroup v1 on AL2023 with grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0" as one fix for old JDK 8 pods hitting out-of-memory kills. A team that took that route has a launch template that will not join a 1.35 cluster, and the 1.35 notes name exactly that case as action required.

The Fargate row is not something you can fix. AWS's 1.35 notes state that Fargate continues to use cgroup v1, without saying how the kubelet is configured there. The practical consequence is that cgroup v2-only features, such as Memory QoS, should not be assumed on Fargate pods.

How to check whether your nodes use cgroup v1 or v2

Run stat -fc %T /sys/fs/cgroup/ on the node: cgroup2fs means cgroup v2 and tmpfs means cgroup v1, per the Kubernetes cgroup v2 documentation. Without SSH access, a node debug pod works, because kubectl debug node mounts the node's root filesystem at /host:

kubectl debug node/<node-name> -it --image=ubuntu -- stat -fc %T /host/sys/fs/cgroup/

Check one node per node group and per launch template version, not one node per cluster. The failures come from the outlier group that a previous engineer customised, and from Karpenter node classes or self-managed groups that point at a custom AMI ID.

What failCgroupV1: false buys you, and what it does not

Setting failCgroupV1: false in the kubelet configuration lets a cgroup v1 node start on 1.35 and later. The v1.37 sneak peek calls it a short-term fix and confirms it still works in 1.37.

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

On AL2023, kubelet settings go through the nodeadm NodeConfig under spec.kubelet.config, which the AWS AL2023 upgrade guide shows with maxPods. Test the override on one node group before relying on it.

The strongest case for the override is real: it decouples the control-plane upgrade from the node-image migration, so you can beat 2 December and migrate nodes calmly. The case against it is what you give up. The sneak peek says in-place pod resizing and tiered memory protection depend entirely on cgroup v2, and the October cgroup v2 post says Memory QoS is available only on cgroup v2 nodes. You would also be carrying a setting with removal no earlier than 1.38 on the KEP. Use it to buy weeks, not as the plan.

If you run kubeadm clusters alongside EKS, the check arrives earlier. With kubelet v1.35 or later, kubeadm's SystemVerification preflight returns an error on cgroup v1 during kubeadm init, join and upgrade, according to the same post.

The workloads that break when nodes move to cgroup v2

Moving the node is the easy half. Software that reads the cgroup filesystem directly can misread its memory limit on cgroup v2 and size itself to the whole node. The Kubernetes migration guidance lists the minimum versions:

• OpenJDK / HotSpot: jdk8u372, 11.0.16, 15 and later.
• Node.js: v20.3.0 and later read cgroup v2 memory limits; the v18 line does not reliably detect them. If you are still choosing a Node line, our note on Node 20 end of life covers which one to target.
• uber-go/automaxprocs: v1.5.1 or higher.
• cAdvisor run as a stand-alone DaemonSet: v0.43.0 or later.

The node side has its own floor: Linux kernel 5.8 or later, containerd v1.4 or later, or CRI-O v1.20 or later. The AWS FAQ lists AL2023 on kernel 6.1 and 6.12, so the stock image clears that easily. Look further ahead on the runtime, though: the EKS 1.35 notes say 1.35 is the last Kubernetes release supporting containerd 1.x.

EKS 1.35 upgrade checklist for cgroup v2

1. List every node group, Karpenter node class and self-managed group, with its AMI ID or AMI family.
2. Run the stat check on one node from each; flag anything returning tmpfs.
3. Search launch templates and user data for systemd.unified_cgroup_hierarchy=0.
4. Audit images for JDK, Node.js, automaxprocs and cAdvisor versions below the minimums above.
5. Move flagged groups to AL2023 or Bottlerocket; set failCgroupV1: false only where that cannot finish before the control-plane upgrade.
6. Record every override with an owner and a removal date before 1.38.

The decision before 2 December

If the check finds nothing, the cgroup change is a non-event and you can upgrade to 1.35 on its own merits. If it finds a cgroup v1 group, decide now whether you migrate it before the control-plane upgrade or ship the override with a dated plan to remove it; extended support costs $0.60 per cluster per hour against $0.10 on standard support, so drifting past the date is the expensive third option.

Our DevOps and cloud engineering team runs exactly this audit: node inventory, the AL2023 or Bottlerocket move, and the workload version checks, scoped to the clusters you need upgraded before 2 December. If the work is wider than one upgrade, our Kubernetes implementation practice covers the node-image and runtime changes that follow. Tell us which node groups you have and we will tell you what the check is likely to find.