1. cgroup v2 概述：诞生背景、核心差异与统一层级树设计

1.1 诞生背景：为什么需要 cgroup v2？

cgroup（Control Groups）是 Linux 内核提供的一种资源隔离与管控机制，自 2007 年合并入主线以来，cgroup v1 在容器、虚拟化、系统资源管理等场景中得到了广泛应用。然而，随着生产环境对资源观测精度、安全隔离性和运维复杂度的要求不断提高，v1 的设计缺陷逐渐暴露，成为可观测性与延迟分析的瓶颈。

cgroup v2 自 Linux 4.5 开始引入，并在 4.15 之后逐步稳定。它并非简单的增量升级，而是对资源管控模型的重构，核心目标包括：

• 统一层级树：所有子系统挂载到同一棵层级树，消除多树并行带来的管理混乱。
• 安全增强：限制非特权用户对 cgroup 的写入权限，减少攻击面。
• 资源压力观测：引入 PSI（Pressure Stall Information）机制，直接输出 CPU、内存、IO 的延迟水位。
• 线程级管理废弃：cgroup v2 只管理进程，不再支持线程级迁移，简化内核路径。

1.2 核心差异：v1 与 v2 的对比

下表从架构、资源模型、可观测性、安全与兼容性五个维度，系统对比 v1 与 v2 的核心差异：

1.3 统一层级树设计理念

统一层级树（Unified Hierarchy）是 cgroup v2 最核心的设计变更。它将所有资源控制器（Controller）挂载到同一棵树的同一个挂载点（通常为 /sys/fs/cgroup），每个 cgroup 目录下同时包含 cpu、memory、io 等所有子系统的控制文件。

这种设计的核心理念包括：

• 资源视图一致：一个进程组的所有资源限制在同一目录下配置，避免 v1 中跨树查找的混乱。
• 内核对齐：内核在遍历 cgroup 时只需遍历一棵树，减少锁竞争和路径开销。
• 子节点继承：子 cgroup 自动继承父节点的资源上限，形成清晰的资源配额链。
• 无内部进程：非根 cgroup 只能包含子 cgroup 或进程，不能同时包含两者，避免资源统计歧义。

下图展示了统一层级树的结构与资源控制器的分布关系：

1.4 无内部进程规则与资源继承

统一层级树引入了一个关键约束：非根 cgroup 不能同时包含子 cgroup 和进程。这意味着：

• 如果一个 cgroup 目录下有子目录，则它自身不能附加任何进程。
• 所有进程必须位于叶子节点（leaf node）中。
• 资源限制从根到叶子逐层继承，父节点的上限是子节点的硬天花板。

下图对比了 v1 的多树碎片化与 v2 的统一树设计：

1.5 从 v1 迁移到 v2 的注意事项

对于正在运行 v1 的生产环境，迁移到 v2 需要关注以下关键点：

• 内核版本：建议使用 Linux 5.2+，PSI 和 io 控制器在 5.0+ 已稳定。
• systemd 版本：systemd v242+ 默认使用 cgroup v2，可通过 systemd.unified_cgroup_hierarchy=1 启用。
• 容器运行时：Docker 20.10+、containerd 1.5+、Podman 3.0+ 已原生支持 v2。
• 监控工具：确保 cadvisor、Prometheus node_exporter 等工具支持 v2 的指标路径。
• 回退方案：保留 v1 混合模式（hybrid mode）作为过渡，但混合模式会降低 PSI 的精度。