为什么要先确认 cgroup 版本
cgroup v1 与 v2 在内存、IO、swap 相关行为上差别明显：限制类问题应当先看 docker info 里的 Cgroup Version 与 Cgroup Driver，再讨论具体参数。同一台机器上集成的组件（例如编排代理）也要与 Docker 使用一致的驱动。
基本信息
| 查看 | docker info 的 Cgroup Version 与 Cgroup Driver |
|---|---|
| 影响面 | 内存、swap、IO 权重等选项映射不同 |
| 联动 | 同机的编排代理需与 Docker 驱动一致 |
| 宿主侧信息 | /sys/fs/cgroup/cgroup.controllers 与 mount 输出 |
| 提示位 | docker info 顶部的 WARNING 段 |
典型使用场景
- 内存或 swap 限制不生效时，先确认 cgroup 版本再改参数
- 排查 IO 权重类参数为什么没有效果
- 部署编排代理时核对两边驱动设置是否一致
- 系统升级后资源统计异常，回溯 cgroup 版本变化
- 写环境基线文档时记录版本与驱动，避免后续误判
- 对比新旧宿主的 cgroup 版本，判断升级是否引入了行为差异
核对命令
核对命令
docker info -f 'CgroupVersion={{.CgroupVersion}} Driver={{.CgroupDriver}}'
cat /sys/fs/cgroup/cgroup.controllers 2>/dev/null # cgroup v2 可用控制器列表
mount | grep cgroup | head -3 # 挂载层级，判断 v1 或 v2
docker info 2>/dev/null | grep -iA3 WARNING # 关注能力缺失提示v1 与 v2 的差异
| 项目 | cgroup v1 | cgroup v2 |
|---|---|---|
| 挂载层级 | 多层级，按控制器分开 | 统一层级 |
| 内存软限 | memory.soft_limit_in_bytes | memory.low |
| IO 权重 | blkio.weight | io.weight |
| swap 相关 | memory.memsw 系列 | memory.swap 系列 |
文本版 docker info 顶部的 WARNING 段会提示 cgroup 相关能力缺失（例如不支持 swap 限制），环境排查先读它。
看到 WARNING: No swap limit support 时，内存与 swap 限制行为可能不符合预期，需要提前告知业务方，别等上线才发现。
编排代理与 dockerd 的 cgroup 驱动不一致会带来资源统计与限制行为差异，混合部署时要逐项核对。
不同发行版默认的 cgroup 版本不同，换机型或换镜像模板时资源参数需要重新验证，不要沿用旧机器的结论。
cgroup v2 的目录结构与 v1 不同，监控采集脚本里硬编码 v1 路径会在新版机器上采不到数据，采集口径要按版本分别适配。
容器内 /sys/fs/cgroup 的可见范围受命名空间设置影响，核对限制数值时先确认容器内看到的是自己那层视图还是宿主视图。