How to Enable cgroup v1 for Kubernetes 1.34 Bottlerocket AMIs—and What’s Different from 1.33

Background

Kubernetes version v1.34 was released in August 2025. and when deploying Bottlerocket nodes in a v1.34 cluster, it’s strongly recommended to use the AMI version that matches the cluster version. For both Bottlerocket v1.33 and v1.34 AMIs, the default cgroup version is v2, as confirmed by running:

stat -fc %T /sys/fs/cgroup/

• Returns cgroup2fs → cgroup v2
• Returns tmpfs → cgroup v1

However, some users may need to temporarily revert to cgroup v1 for example, to maintain compatibility with legacy workloads or monitoring tools built around cgroup v1 semantics.

In this article, we compare how to enable cgroup v1 on Bottlerocket AMIs for Kubernetes v1.33 versus v1.34 and explain why the same configuration no longer works in v1.34.

Configurations in 1.33 AMIs

On Bottlerocket AMIs for Kubernetes v1.33, enabling cgroup v1 is straightforward. You simply add the following configuration to your userdata script:

[settings.boot]
reboot-to-reconcile = true
[settings.boot.init]
"systemd.unified_cgroup_hierarchy" = ["0"]

After launching the node, cgroup v1 is active:

$ stat -fc %T /sys/fs/cgroup/
tmpfs

Configurations in 1.34 AMIs

When applying the same configuration to Bottlerocket AMIs for Kubernetes v1.34, the setting has no effect, the system remains on cgroup v2:

$ stat -fc %T /sys/fs/cgroup/
cgroup2fs

Why Does This Happen?

Inspecting the EC2 system log reveals the root cause:

[    0.063278] RETBleed: WARNING: Spectre v2 mitigation leaves CPU vulnerable to RETBleed attacks, data leaks possible!
[    0.476073] systemd[1]: Legacy cgroup v1 configured. This will stop being supported soon.
[    0.477091] systemd[1]: Will proceed with cgroup v2 after 30 s.
[    0.477877] systemd[1]: Set systemd.unified_cgroup_hierarchy=1 to switch to cgroup v2 or set SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1 to reenable v1 temporarily.
[!p]104[?7h
Welcome to Bottlerocket OS 1.49.0 (aws-k8s-1.34)!

Starting with newer systemd versions (used in Bottlerocket ≥1.49, which ships with k8s-1.34 variants), cgroup v1 support is being actively phased out. Even if systemd.unified_cgroup_hierarchy=0 is set, systemd defaults to cgroup v2 after a brief delay unless you explicitly opt in to legacy mode.

According to the Bottlerocket API documentation, the correct way to force cgroup v1 on v1.34 AMIs is:

[settings.boot.kernel-parameters]
"systemd.unified_cgroup_hierarchy" = ["0"]
"SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE" = ["1"]
[settings.boot]
reboot-to-reconcile = true

Once applied and the node reboots, cgroup v1 is successfully enabled:

$ stat -fc %T /sys/fs/cgroup/
tmpfs

Conclusion

This article highlighted a subtle but critical change in Bottlerocket AMIs for Kubernetes v1.34: due to upstream systemd deprecation of cgroup v1, simply setting systemd.unified_cgroup_hierarchy=0 is no longer sufficient.

To enable cgroup v1 on Bottlerocket 1.34 AMIs, you must also set the SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1 kernel parameter.

While this provides a temporary bridge for legacy compatibility, users are strongly encouraged to migrate workloads to cgroup v2, which offers better isolation, unified hierarchy, and support for modern Kubernetes features (e.g., MemoryQoS, pressure stall information).