cgroup v2 采用统一的层级结构和改进的内存管理机制，兼容 Kubernetes 后续版本的增强功能。建议将节点迁移至默认启用 cgroup v2 的新版操作系统，以提升集群稳定性与资源管理效率。
Cgroup版本说明
Linux内核提供cgroup v1和cgroup v2两个版本，用于限制、记录和隔离进程组使用的物理资源（如CPU、内存、I/O等）。cgroup v2是新一代的cgroup 接口，在设计上解决了 v1 的多控制器层级问题，提供了更一致的资源控制能力。两者在通用接口与子系统组织方式上存在差异，直接访问 cgroup 文件系统的应用程序需进行适配。
详见cgroup v1与cgroup v2的区别。
Kubernetes 自 1.31 版本 起将cgroup v1支持调整为维护模式，建议迁移至cgroup v2。cgroup v2主要优势包括：
提升稳定性：采用统一的内存核算模型，有效管理页面缓存（Page Cache），解决cgroup v1中高磁盘I/O应用抢占内存、导致其他应用被OOMKilled的问题。
统一的层级结构：所有资源控制器（如 CPU、内存）集中于单一层级，避免cgroup v1中多层级并存带来的配置冲突与管理复杂性，简化资源视图与策略定义。
增强的资源可观测性：引入压力失速信息（Pressure Stall Information, PSI），量化应用因等待 CPU、内存或 I/O 资源而阻塞的时间，为性能瓶颈分析提供精细化指标支持。
检查节点cgroup版本
迁移前，可登录节点，执行以下命令来确认当前的cgroup版本。
# 登录到目标节点后执行
stat -fc %T /sys/fs/cgroup/
# 预期输出:
# cgroup2fs --> 代表 cgroup v2
# tmpfs --> 代表 cgroup v1
迁移步骤
节点层面：更换操作系统
ACK集群节点的cgroup版本由其操作系统决定。如需迁移，请在节点池维度更换为支持cgroup v2的新版操作系统。ACK中默认使用cgroup v2的操作系统包括Alibaba Cloud Linux 3、ContainerOS 3.3及以上版本、RHEL 9及以上版本、Ubuntu 22及以上版本。
操作步骤及相关注意事项，请参见更换操作系统。
应用层面：确保工作负载兼容性
由于 cgroup v1 与 v2 的文件系统结构和参数命名不兼容，任何直接读取 /sys/fs/cgroup 路径的应用均需验证或升级以支持 cgroup v2。
分类 | 说明 |
Java应用 |
|
Go应用 | 若使用了 uber-go/automaxprocs 包，需升级至 v1.5.1 及以上版本。 |
cAdvisor | 如果使用cAdvisor作为独立的DaemonSet来监控Pod和容器，需更新至 v0.43.0 及以上版本。 |
Nginx Ingress | 旧版本可能因无法正确解析 cgroup v2 中的 CPU 核数信息而导致内存超限并触发 OOM，需升级至 v1.11.2 及以上版本。详见GitHub Issue #9665。 升级ACK Nginx Ingress Controller时，请参见升级Nginx Ingress Controller组件。 |
其他需要关注的应用与组件
第三方监控与APM Agent：Prometheus Node Exporter、Datadog Agent、SkyWalking 等工具在采集节点或容器指标时依赖 cgroupfs 数据源。未适配 cgroup v2 的版本可能导致数据缺失或异常。建议查阅官方文档，升级至明确声明支持 cgroup v2 的版本。
安全与审计工具：Falco、Sysdig 等通过 cgroup 信息关联事件归属。若组件版本不兼容，可能导致检测规则失效或误报。建议升级至兼容版本，并在测试环境验证规则有效性。
性能敏感型应用与自定义脚本：部分应用启动脚本会读取 cgroup 文件实现自动调优（如根据 CPU 配额设置线程数）。此类逻辑在 cgroup v2 下因路径变更而失效。应审查相关脚本，更新为适配 cgroup v2 的读取方式。
生产环境使用建议
应用兼容性
审查自研应用或脚本，确保其不依赖cgroup v1文件系统（如
cpu.cfs_quota_us）。由于文件系统接口不兼容，此类逻辑在cgroup v2下将失效，必须进行适配。节点自定义配置
更换操作系统会重置节点。所有自定义修改需通过节点池功能进行持久化，否则在节点重建后将丢失。相关配置方式及注意事项，请参见：
管理节点池OS参数（sysctl、THP）
监控告警：建议启用阿里云Prometheus监控，持续观测集群整体健康状态及关键容器的资源使用趋势，及时发现异常。