Linux 内核控制组（cgroup）深度解析：从设计原理到生产实践

摘要：控制组（cgroup）是 Linux 内核提供的一种机制，用于限制、记录和隔离进程组所使用的物理资源（CPU、内存、磁盘IO、网络等）。本文深入剖析 cgroup 子系统的架构设计、核心数据结构、控制器实现原理，以及 cgroup v1 到 v2 的重大架构演进，并结合容器技术（Docker/Kubernetes）探讨其在生产环境中的最佳实践。

一、cgroup 的起源与设计哲学

cgroup 最早由 Google 工程师 Paul Menage 和 Rohit Seth 在 2006 年发起，最初命名为"Process Containers"。2007 年合入 Linux 主线内核（2.6.24 版本）。其核心设计哲学是将资源控制与进程隔离两个关注点分离——资源控制由 cgroup 负责，进程隔离由 namespace 负责。

cgroup 的设计目标：

• 统一接口：为不同的资源控制提供统一的用户态接口
• 层级结构：支持树形层次化的进程分组与资源分配
• 细粒度控制：精确到每个进程组的资源使用限制
• 可组合性：不同控制器可以独立配置，灵活组合

二、cgroup v1 架构与核心组件

2.1 核心概念

cgroup v1 由三个核心概念组成：

子系统（subsystem / controller）：每种资源类型对应一个核心子系统，包括 cpu、memory、blkio、devices、net_cls、freezer、cpuacct 等。

层级（hierarchy）：一棵由 cgroup 实例构成的树形结构，每个进程属于且仅属于某个层级中的一个 cgroup 节点。

子系统-层级绑定：子系统可以挂载到不同的层级组合，这种灵活性也是 v1 后期混乱的根源。

2.2 关键数据结构

// 核心 cgroup 结构 (简化版，基于 kernel 5.x)
struct cgroup {
    struct kernfs_node *self;        // 虚拟文件系统节点
    unsigned long flags;             // cgroup 标志位
    int level;                       // 当前层级深度

    struct cgroup_subsys_state **subsys[MAX_CGROUP_TYPE_NR];

    int nr_populated_csets;          // 存活子 cgroup 数
    int nr_populated_threaded_csets: 1;

    struct cgroup *parent;           // 父 cgroup
    struct list_head sibling;        // 兄弟节点链表
    struct list_head children;       // 子节点链表

    struct cgroup_root *root;        // 指向根层级
};

// 子系统状态 - 针对每种控制器的实例化
struct cgroup_subsys_state {
    struct cgroup *cg;              // 所属 cgroup
    struct cgroup_subsys *ss;       // 指向子系统定义

    struct percpu_ref refcnt;       // 引用计数

    unsigned long flags;
    u64 id;                         // 唯一 ID（cgroup v2 关键标识）
};

2.3 三大子系统深度分析

（1）Memory Controller

内存控制器负责限制和控制 cgroup 的内存使用。其核心字段包括 memory.limit_in_bytes、memory.usage_in_bytes、memory.oom_control 等。内核通过 LRU（Least Recently Used）链表来实现内存回收，当内存使用接近 limit 时触发直接回收（direct reclaim），超过 limit 则触发 OOM Killer。

// 核心内存控制数据结构
struct mem_cgroup {
    struct cgroup_subsys_state css;  // 基类：嵌入 cgroup 子系统状态

    struct page_counter memory;      // 内存使用计数器
    struct page_counter swap;        // Swap 使用计数器
    struct page_counter kmem;        // 内核内存计数器
    struct page_counter tcpmem;      // TCP socket 缓冲区计数

    unsigned long soft_limit;        // 软限制（尽量遵守）
    unsigned long high;              // throttle 高水位线
    unsigned long max;               // 硬限制
    unsigned long min;               // 保证最小内存（不能被回收）
    unsigned long low;               // 低水位线（优先保护）

    int oom;                         // OOM 标志
    int oom_group;                   // 整体 OOM 标志

    struct memcg_vmstats vmstats;    // 虚拟内存统计
    struct memcg_vmstats_percpu *vmstats_percpu;

    struct memcg_kmem_state kmem_state;
    struct list_head oom_notify;     // OOM 通知链
};

内存控制器的 OOM 处理流程：当 cgroup 内存超过限制时，内核首先尝试回收该 cgroup 内的 page cache 和 slab 缓存，若回收失败则调用 OOM Killer 选择进程终止。Linux 4.19+ 引入了 PSI（Pressure Stall Information）来提前预警内存压力。

（2）CPU Controller（cpu + cpuacct）

CPU 资源控制通过 CFS（Completely Fair Scheduler）调度器类实现。cgroup 通过 cpu.cfs_period_us 和 cpu.cfs_quota_us 两个参数来限制 CPU 使用量。

CPU 份额（shares）机制：相对权重分配，适用于非限制型管控。当多个 cgroup 争抢 CPU 时，按 shares 比例分配时间片。默认值为 1024。

CPU 带宽限制（Bandwidth Control）机制：绝对上限限制，通过 period/quota 对实现。例如 period=100000（100ms）、quota=50000 表示在一个周期内该 cgroup 最多运行 50ms，即 0.5 个 CPU 核心。

// CFS bandwidth 控制核心数据
struct cfs_bandwidth {
    rawlock_t lock;
    ktime_t period;
    u64 quota;              // 本周期可用配额（微秒）
    u64 runtime;            // 本周期剩余配额
    u64 hierarchical_quota; // 层级配额

    struct hrtimer period_timer;    // 高精度定时器
    struct list_head throttled_cfs_rq;

    int quota_enabled;
    int timer_active;
};

CFS bandwidth 的核心实现依赖于高精度定时器（hrtimer）。当 cgroup 消耗完配额后，该 cgroup 下的所有进程被挂入 throttled 队列，直到下一周期定时器重新补充 quota。

（3）Block I/O Controller（blkio / io）

块设备 IO 控制在 v1 中通过 blkio 实现，支持权重方式和限速方式两种模式。权重方式使用 blkio.weight（默认 500）实现按比例分配 IO 带宽；限速方式通过 blkio.throttle.read_bps_device 等参数设置绝对上限。

// 权重控制核心结构
struct blkg_conf_ctx {
    struct gendisk *disk;
    struct blkcg_gq *blkg;
    u64 v[BLKCG_MAX_POLICIES];
};

// 限速核心结构
struct throtl_grp {
    struct blkg_policy_data pd;

    u64 bps[2][THROTL_IOSIZE_IDX_COUNT];
    u32 iops[2][THROTL_IOSIZE_IDX_COUNT];

    unsigned long dispatch[2];
    unsigned long last_low_overflow_time[2];
};

三、cgroup v2：架构重构与关键改进

3.1 为什么需要 v2

cgroup v1 在实际使用中暴露出多个架构缺陷：

• 层级碎片化：多个层级各自为政，控制器间资源分配难以协调
• 线程模式不一致：子组加入进程后无法再添加线程，导致多线程应用管理困难
• 接口语义混乱：部分控制器路径重复，stat 文件格式不统一
• 写回控制复杂：memory 写回与 IO 控制分属两个层级，无法协同

3.2 v2 的核心架构变化

统一层级（Unified Hierarchy）：v2 只有一个全局层级树，所有控制器共同作用于同一个树结构。

内在化约束：v2 规定只有不包含进程的 cgroup 节点（即只有子节点的"内部节点"）才能启用子节点未使用的控制器。

线程模式改进：v2 支持将进程的各个线程分散到不同的 cgroup，通过 cgroup.threads 接口管理。

增强的资源统计：v2 提供统一格式的 memory.stat、cpu.stat、io.stat 接口，输出格式标准化。

3.3 v2 关键控制器改进

Memory Controller v2：

• 取消了 kmem 计数器拆分，统一为 memory.stat 中的内核统计
• 新增 memory.high（软限流）和 memory.max（硬限制）两阶段回收策略
• 新增 memory.min（保证预留）和 memory.low（优先回收保护）
• 统一了 swap 控制：memory.swap.max 替代 v1 两个参数
• 取代 v1 的 OOM killer 为更柔性的内存压力通知机制

IO Controller v2：

• 统一使用 io.weight 和 io.max 接口
• 支持 per-IO-statistics 细粒度追踪
• 与 memory 写回更好的协同控制
• 使用基于 blk-iocost 的自适应模型替代静态限速

CPU Controller v2：

• 使用 cpu.weight 替代 v1 的 cpu.shares（权重范围 1-10000）
• 新增 cpu.max.burst 支持突发带宽
• 新增 cpu.pressure 提供 PSI 压力信息

四、cgroup 的底层实现机制

4.1 虚拟文件系统（cgroupfs）

cgroup 通过虚拟文件系统暴露用户态接口。v1 使用 cgroupfs 伪文件系统挂载，v2 使用 c2groupfs。

// v2 虚拟文件系统挂载
mount -t cgroup2 none /sys/fs/cgroup

// v2 统一层级树结构
/sys/fs/cgroup/
  cgroup.controllers
  cgroup.subtree_control
  cgroup.events
  cgroup.max.depth
  cgroup.max.descendants
  cgroup.threads
  cgroup.procs
  cpu.max                  # CPU 带宽限制
  cpu.weight               # CPU 权重分配
  cpu.pressure             # CPU 压力信息
  io.max                   # IO 限速配置
  io.weight                # IO 权重分配
  io.stat                  # IO 使用统计
  memory.current           # 内存使用量
  memory.high              # 内存软限制
  memory.max               # 内存硬限制
  memory.min               # 内存预留保证
  memory.low               # 内存低水位保护
  memory.stat              # 内存详细统计
  memory.swap.max          # Swap 限制

4.2 进程迁移与资源记账

进程加入 cgroup 流程:
write(cgroup.procs, "PID")
  -> vfs 调用 cgroup_migrate()
  -> cgroup_procs_write() 解析目标 PID
  -> cgroup_attach_task() 执行迁移:
     1. 从旧 cgroup 移除引用计数
     2. 遍历所有激活的 subsystem 调用 css_attach()
     3. 为新 cgroup 增加引用计数
     4. 更新进程的 cset（cgroup_set）链表
     5. 触发 cgroup.events 更新 populated 状态

4.3 内核参数与编译选项

CONFIG_CGROUPS=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_SCHED=y
CONFIG_CPUSETS=y
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
CONFIG_BLK_CGROUP=y
CONFIG_CGROUP_NET_CLASSID=y
CONFIG_CGROUP_NET_PRIO=y
CONFIG_CGROUP_HUGETLB=y
CONFIG_CGROUP_PIDS=y
CONFIG_CGROUP_RDMA=y
CONFIG_CGROUP_BPF=y          # eBPF hook for cgroup (4.10+)
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP2_FS=y          # cgroup v2 支持

五、容器视角下的 cgroup 实践

5.1 Docker 中的 cgroup 应用

Docker 引擎通过 cgroup 实现容器资源限制，每种限制参数映射到底层 cgroup 文件：

# Docker 资源限制示例
docker run \
  --cpus 1.5 \
  --memory 512m \
  --memory-reservation 256m \
  --blkio-weight 500 \
  --device-read-bps /dev/sda:10mb \
  --device-write-iops /dev/sda:1000 \
  --pids-limit 100 \
  ubuntu:22.04

# 底层对应关系（cgroup v1）
/sys/fs/cgroup/memory/docker/$CID/memory.limit_in_bytes
/sys/fs/cgroup/cpu/docker/$CID/cpu.cfs_quota_us
/sys/fs/cgroup/blkio/docker/$CID/blkio.throttle.read_bps_device

5.2 Kubernetes 中的 cgroup 管控

apiVersion: v1
kind: Pod
metadata:
  name: resource-demo
spec:
  containers:
  - name: app
    image: nginx:1.24
    resources:
      requests:
        cpu: "500m"
        memory: "256Mi"
      limits:
        cpu: "1000m"
        memory: "512Mi"
        ephemeral-storage: "2Gi"

Kubernetes 的 cpu-manager-policy 会利用 cpuset 控制器的 topology-aware 分配，将容器绑定到特定的 CPU 核心，减少跨 NUMA 节点访问延迟。

5.3 cgroup 与 Namespace 的协同

cgroup 负责"能用多少"，namespace 负责"能看到什么"。在容器技术中，二者密切配合：cgroup 提供资源配额，namespace 提供独立视图（PID、mount、network、user、hostname 等）。

六、生产环境监控与调优

6.1 关键监控指标

在生产 Kubernetes 集群中，以下 cgroup 指标是性能诊断的重要依据：

# CPU 压力指标 (PSI)
cat /sys/fs/cgroup/cpu.pressure
some avg10=0.00 avg60=0.00 avg300=0.00 total=0
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

# IO 统计
cat /sys/fs/cgroup/io.stat
259:0 rbytes=10485760 wbytes=2097152 rios=500 wios=100 dbytes=0 dios=0

# 内存统计关键项
cat /sys/fs/cgroup/memory.stat
anon 268435456            # 匿名映射
file 134217728            # Page cache
active_anon 268435456
workingset_refault 0      # 工作集缺页重填
pgmajfault 100             # 主要缺页
pgscan 5000                # 页扫描
pgsteal 3000               # 页回收

6.2 常见陷阱与调优建议

陷阱 1：内存限制过紧导致 OOM

设置 memory.limit 时未预留足够的缓冲区，导致 page cache 无法正常回收而触发 OOM。建议为应用预留 10-20% 的 buffer，或使用 memory.high 作为软限流而非硬限制。

陷阱 2：CPU 配额计算错误

cfs_quota 和 cfs_period 的单位是微秒。Docker 中 --cpus 1.5 自动换算为 quota=150000/period=100000。手动设置时 quota=100000 才表示 1 个核心。

陷阱 3：IO 控制层级配置冲突

v1 中 blkio 和 memory 分属不同层级，写回压力无法被 IO 限制感知。v2 中通过 io.weight 和 memory.high 的协同解决了这个问题。

调优建议：

• 使用 cgroup v2（Linux 5.14+ 已成熟），享受统一层级和更好的资源协调
• 为关键应用设置 memory.min 保证资源不被其他 cgroup 回收
• 使用 PSI 指标（cpu.pressure / memory.pressure / io.pressure）提前预警资源瓶颈
• 在 NUMA 系统中，配合 cpuset 控制器避免跨节点内存访问
• 监控 memory.stat 中的 workingset_refault 指标，判断工作集是否超出内存限制

七、前沿发展：cgroup 与 eBPF 的融合

Linux 4.10+ 引入了 cgroup-bpf 功能，允许将 eBPF 程序附加到 cgroup 钩子上，实现：pod 级别的网络策略 enforcement（Cilium 使用此机制）、IO 路径上的跟踪与统计、基于 cgroup 的系统调用过滤。这为 cgroup 从"资源控制器"演进为"可观测性与安全控制平面"开辟了新道路。

// cgroup-bpf 示例：限制 socket 创建
SEC("cgroup/sock_create")
int block_skb(struct bpf_sock *sk) {
    if (sk->family != AF_INET)
        return 0;
    return 1;
}

// 通过 bpftool 加载到特定 cgroup
bpftool cgroup attach /sys/fs/cgroup/myapp \
    sock_create obj /opt/bpf/cgroup_sock.o

八、总结

cgroup 从 Linux 2.6.24 的简单资源控制器发展至今，已成为现代容器基础设施的基石。理解 cgroup 的底层架构——从 subsys 层级绑定到 v2 统一层级演进，从计数器实现到 PSI 压力指标，从传统的限速控制到与 eBPF 融合的可编程控制——对于构建稳定、高效、可观测的云原生系统至关重要。随着 Linux 6.x 内核中 cgroup 的持续增强（如 cgroup.rstat 高性能统计接口、支持 threaded controllers、更好的 memory QoS），cgroup 正在从"能用"走向"好用"和"易用"。

核心知识点回顾：cgroup v1（多子系统多层级，灵活但混乱）到 cgroup v2（统一层级，简洁但严格）。三大核心控制器（CPU/memory/IO）通过 hrtimer 定时补充配额实现带宽限制，通过 per-cpu 引用计数实现高效统计。PSI 指标提供 pressure 感知优于轮询机制。eBPF 扩展使 cgroup 超越了资源管控的边界。