All Products
Search

This Product

    Container Service for Kubernetes:Migrate nodes to cgroup v2

    Document Center

    Container Service for Kubernetes:Migrate nodes to cgroup v2

    Last Updated:Jun 15, 2026

    cgroup v2 unifies resource control, improves memory handling, and ensures Kubernetes compatibility.

    Cgroup versions

    The Linux kernel provides cgroup v1 and cgroup v2 to limit, account for, and isolate physical resources (such as CPU, memory, and I/O) for process groups. cgroup v2 resolves v1's multiple-hierarchy issues with a unified controller model. The filesystem interfaces are incompatible, so applications that directly access cgroupfs must be updated.

    See Differences between cgroup v1 and cgroup v2.

    Kubernetes v1.31 moved cgroup v1 support to maintenance mode, and v1.35 dropped support. Key advantages of cgroup v2:

    • Improved stability: Unified memory accounting manages the page cache effectively, resolving cgroup v1's issue where high-disk-I/O applications preempt memory and cause OOMKilled events.

    • Unified hierarchy: All resource controllers (such as CPU and memory) share a single hierarchy, eliminating configuration conflicts from cgroup v1's parallel hierarchies.

    • Enhanced resource observability: Pressure Stall Information (PSI) measures time stalled on CPU, memory, or I/O, providing fine-grained metrics for bottleneck analysis.

    Check the cgroup version

    Log on to a node and run the following command to check its cgroup version.

    # Run this command after logging on to the target node
stat -fc %T /sys/fs/cgroup/

# Expected output:
# cgroup2fs  --> Indicates cgroup v2
# tmpfs      --> Indicates cgroup v1

    Migration procedure

    Node level: Change the operating system

    The cgroup version of a node is determined by its operating system.

    Application level: Ensure workload compatibility

    cgroup v1 and v2 have incompatible filesystem structures and parameter names. Any application that directly reads /sys/fs/cgroup must be verified or upgraded for cgroup v2.

    Category

    Description

    Java applications

    • DragonWell: 11.0.16.12, 8.15.16-GA, and later.

    • OpenJDK/HotSpot: jdk8u372, 11.0.16, 15, and later.

    • IBM Semeru Runtimes: 8.0.382.0, 11.0.20.0, 17.0.8.0, and later.

    • IBM Java: 8.0.8.6 and later.

    Go applications

    If you use uber-go/automaxprocs, upgrade to v1.5.1 or later.

    cAdvisor

    If you deploy cAdvisor as a standalone DaemonSet, update to v0.43.0 or later.

    Nginx Ingress

    Older versions may trigger OOMKilled errors due to incorrect CPU core parsing in cgroup v2. Upgrade to v1.11.2 or later. See GitHub Issue #9665.

    To upgrade the ACK Nginx Ingress Controller, see Upgrade the Nginx Ingress Controller component.
    Other applications and components

    • Third-party monitoring and APM agents: Tools such as Prometheus Node Exporter, Datadog Agent, and SkyWalking read cgroupfs for metrics. Incompatible versions may cause data loss or anomalies. Upgrade to a version that supports cgroup v2.

    • Security and auditing tools: Tools such as Falco and Sysdig use cgroup data to attribute events. Incompatible versions may cause detection rule failures or false positives. Upgrade to a compatible version and verify rules in a test environment.

    • Performance-sensitive applications and custom scripts: Startup scripts that read cgroup files for auto-tuning (such as setting thread count from CPU quota) will fail under cgroup v2 due to path changes. Review and update these scripts for cgroup v2.

    Production recommendations