Linux Cgroup V2 与容器资源隔离深度实战：从内存控制到 eBPF 联动

Linux Control Groups（cgroup）是 Linux 内核提供的一种资源隔离机制，能够对进程组的 CPU、内存、I/O、网络等资源进行精细化管控。随着容器技术的普及，cgroup 已成为云原生基础设施的核心组件。2016 年 Linux 4.5 内核正式发布 cgroup v2，经过数年迭代，目前已成为容器引擎的默认配置。本文将深入剖析 cgroup v2 的架构设计、核心机制、控制器实现以及与容器运行时的集成实践。

一、Cgroup V1 到 V2 的设计演进

cgroup v1 存在几个根本性问题：资源控制器挂载不一致、缺乏统一事件通知、层级结构设计复杂。cgroup v2 引入了统一的层级树设计，所有控制器挂载在同一个文件系统中，彻底解决了 v1 时代的碎片化问题。

与 v1 的关键区别包括：

• 统一层级树：所有资源控制器共享单一棵树，避免多套层级树的复杂交互
• 进程级别资源计数：一个进程只属于一个 cgroup，消除 v1 中一个进程属于多个同层级 cgroup 的状态不一致问题
• 启用/禁用语义改进：通过 cgroup.controllers 和 cgroup.subtree_control 文件精确控制子树可用的控制器
• OOM 事件通知：引入 cgroup.events 和压力通知机制，实现实时监控

从内核实现来看，cgroup v2 通过统一的入口代码路径和统一的数据结构（cgroup_subsys_state），减少了内核代码复杂度，提升了跨控制器的可维护性。

二、Cgroup V2 层次结构与组织模型

cgroup v2 采用单一树形结构，根节点为 /sys/fs/cgroup。每个 cgroup 都是一个目录，包含以下核心控制文件：

/sys/fs/cgroup/
├── cgroup.controllers      # 本层可用的控制器列表
├── cgroup.subtree_control  # 子树启用的控制器
├── cgroup.events           # populated/frozen 事件
├── cgroup.max.depth         # 子树最大深度
├── cgroup.max.descendants   # 子树最大后代数
├── cgroup.stat              # 进程统计（nr_descendants等）
└── [控制器特定文件]

子 cgroup 通过创建子目录自动创建。重要约束是进程只能存在于叶子节点，不能同时存在于非叶子节点（V2 排除了 V1 中多归属的设计混乱）。这种约束确保了进程的资源限制来自路径上的所有祖先 cgroup 的交集。

查看当前 cgroup 的归属：

$ cat /proc/self/cgroup
0::/user.slice/user-1000.slice/session-3.scope
# 单根路径格式 0::/path

三、内存控制器深度实战

内存控制器（memory）是 cgroup v2 中最复杂的控制器之一，提供精细化内存使用限制和监控能力。

3.1 核心参数

参数	含义	默认值
memory.max	内存硬限制，超限触发 OOM	max
memory.high	内存高水位限制，触发回收压力	max
memory.low	内存保护低水位，优先不被回收	0
memory.min	内存保护硬阈值，绝对不会被回收	0
memory.swap.max	交换空间限制	max
memory.pressure	内存压力通知（PSI）	-

3.2 容器内存限制示例

# 创建 cgroup，设置 1GB 硬限制和 800MB 高水位
$ mkdir /sys/fs/cgroup/container-app
$ echo "1G" > /sys/fs/cgroup/container-app/memory.max
$ echo "800M" > /sys/fs/cgroup/container-app/memory.high
$ echo "100M" > /sys/fs/cgroup/container-app/memory.min

# 将进程加入 cgroup
$ echo $$ > /sys/fs/cgroup/container-app/cgroup.procs

# 查看内存统计
$ cat /sys/fs/cgroup/container-app/memory.stat
anon 262144
file 1048576
kernel_stack 16384
pagetables 8192
...
$ cat /sys/fs/cgroup/container-app/memory.current
1073741824

3.3 内存保护与 OOM 控制

memory.min 提供硬保护，确保该 cgroup 的页面不会被内核回收器（kswapd）回收，适合对延迟敏感的关键应用。memory.low 则提供软保护，仅在系统内存紧张时其他 cgroup 优先被回收。

通过 cgroup.oom.group 可设置 OOM 事件是否按组整个杀死，配合 memory.oom.group 确保关联的容器进程组被一起终止，实现一致性保证。

四、CPU 控制器精细调度

CPU 控制器通过权重和带宽控制两种机制实现 CPU 资源的分配。

4.1 CPU 权重（Shair）

cpu.weight 控制 CPU 时间的相对权重分配，范围 1-10000，默认 100。三个 cgroup 的权重分别为 100/200/300 时，它们将获得 1/3、2/3、3/3 比例的 CPU 时间（当都争用时）。

$ echo "1000" > /sys/fs/cgroup/high-priority/cpu.weight
$ echo "100" > /sys/fs/cgroup/low-priority/cpu.weight

4.2 CPU 带宽控制（CFS Bandwidth Control）

cpu.max 提供硬性带宽限制，格式为 $MAX $PERIOD：

# 每 100ms 内最多使用 50ms CPU（0.5核）
$ echo "50000 100000" > /sys/fs/cgroup/cpu-limited/cpu.max
# 每 100ms 内最多使用 200ms CPU（2核，允许突发）
$ echo "200000 100000" > /sys/fs/cgroup/burst-app/cpu.max
# max 代表不限制
$ echo "max 100000" > /sys/fs/cgroup/unlimited/cpu.max

CFS Bandwidth Control 采用全局定时器而非 per-cgroup 定时器，运行时队列（runtime queue）机制在整个 cgroup 层面汇总统计，使用红黑树管理已配额的调度实体，降低了内核开销。内核 5.18 进一步引入了 cpu.max.burst（内核 5.19+ 的 Burst特性），允许 cgroup 积累未使用的 CPU 配额，实现更灵活的 CPU 使用模式。

4.3 CPU 压力与性能监控

PSI（Pressure Stall Information）通过 cpu.pressure 文件暴露 CPU 争用情况：

$ cat /sys/fs/cgroup/my-app/cpu.pressure
some avg10=12.34 avg60=45.67 avg300=78.90 total=1234567890

配合 cgroup.pressure 接口注册用户态通知，可在压力超过阈值时触发告警，为自动扩容提供信号。

五、I/O 与网络控制器

5.1 I/O 控制器

cgroup v2 的 I/O 控制器整合了 v1 中 blkio 和 io.stat 功能，io.max 支持按设备设置带宽和IOPS的读写限制：

# 限制 /dev/sda 读带宽 10MB/s，读IOPS 1000
$ echo "10485760 rbps=10485760 riops=1000 wbps=5242880 wiops=500"   > /sys/fs/cgroup/db-container/io.max

# 查看 IO 统计
$ cat /sys/fs/cgroup/db-container/io.stat
8:0 rbytes=52428800 wbytes=26214400 rios=1000 wios=500

io.weight 支持类似 CFQ 权重的相对比例分配，实现服务质量保证。

5.2 网络控制器

cgroup v2 本身不提供直接的网络带宽限制，而是通过 BPF 程序集成网络控制。cgroup/skb 和 cgroup/sock 类型的 BPF 程序可在 socket 层面实现网络策略。例如，通过 BPF 程序在 socket 创建时标记 cgroup classid，结合 tc 的 cgroup 过滤器进行带宽控制。

六、Cgroup V2 与容器运行时集成

6.1 runc/containerd 中的使用

从 containerd 1.4+ 和 runc 1.0+ 开始，默认使用 cgroup v2（当系统支持时）。容器配置通过 OCI spec 的 linux.resources 字段映射到 cgroup 文件：

{
  "linux": {
    "resources": {
      "memory": {
        "limit": 1073741824,
        "reservation": 536870912,
        "swap": 2147483648
      },
      "cpu": {
        "shares": 1024,
        "quota": 50000,
        "period": 100000
      },
      "blockIO": {
        "weight": 500
      }
    }
  }
}

在 rootless 模式（非root运行容器）下，cgroup v2 通过 dbus 将 cgroup 子树委派给 systemd 用户实例解决了权限问题，这也是 cgroup v2 相比 v1 的重要生产力提升。

6.2 Kubernetes Cgroup V2 支持

Kubernetes 从 1.20 开始 Alpha 支持 cgroup v2，在 recent 版本中已稳定。kubelet 通过 cgroupDriver=systemd 或 cgroupDriver=cgroupfs 配置 cgroup 驱动，需与容器运行时保持一致：

# kubelet 配置
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd
cgroupRoot: /
systemCgroups: /system.slice
kubeletCGroups: /kubelet.slice

在 Kubernetes 中，Pod 的 QoS（Guaranteed/Burstable/BestEffort）直接映射为 cgroup 的 cpu.shares/memory.min/memory.max 配置，实现 Pod 间的资源隔离。

七、eBPF 与 Cgroup 联动

cgroup v2 与 eBPF 结合提供了前所未有的内核可编程能力。cgroup/skb、cgroup/sock、cgroup/bind4、cgroup/post_bind4、cgroup/sysctl 等 attach 类型允许 BPF 程序挂载到 cgroup 上，对整组进程生效。

典型用例包括通过 BPF 实现容器级别的：

• 网络策略：cgroup 级别访问控制，基于目标 IP/Port 的流量放行
• Socket 优化：为特定 cgroup 自定义 TCP 拥塞控制算法
• 端口绑定控制：限制特定 cgroup 只能绑定指定端口范围
• 权限管理：在 capability check 阶段拦截特权操作

这种结合使得系统管理员可以在应用不感知的情况下，通过 BPF 程序在 kernel 空间实现精细的策略控制——这是 Cgroup V2 区别于 v1 的重要生态优势。

八、性能优化与排错最佳实践

8.1 监控体系搭建

# 使用 bpftrace 观测 cgroup 迁移
bpftrace -e 'tracepoint:cgroup:cgroup_transfer {
  printf("pid=%d from=%s to=%s\n", args->pid,
    str(args->dst_cgrp), str(args->dst_cgrp)); }'

# 通过 systemd-cgtop 实时查看资源
$ systemd-cgtop --order=memory

8.2 Cgroup 调度延迟优化

当 cgroup 频繁创建/销毁时，cgroup.procs 写入操作可能成为瓶颈。在 高性能容器场景（如 Faas），建议：

• 使用 cgroup pool/预分配技术复用已创建的 cgroup 目录
• 限制 cgroup.max.descendants 防止 cgroup 爆炸引发性能抖动
• 利用 delegated domain（threaded cgroup）将叶子节点的资源管理权下放给子系统，减少父 cgroup 锁竞争

8.3 OOM 排错

诊断容器 OOM 的常用方法：

# 查看 OOM 事件计数
$ cat /sys/fs/cgroup/pod-abc123/memory.events
oom 1
oom_kill 3

结合 memory.oom.group=true 和 dmesg | grep -i "oom" 定位问题。在 Kubernetes 中，kubectl describe pod 的 OOMKilled 事件会关联到具体的 cgroup 内存用量。

九、总结与展望

cgroup v2 不仅是对 v1 的改进，更代表了 Linux 资源管理的一次架构升级。其统一层级、PSI 压力通知、与 eBPF 的深度集成，为云原生时代的容器编排提供了坚实的基础。当前社区正在推进的重点工作包括：

• Threaded Resource Control：支持在子 cgroup 中使用线程粒度的资源管控，适合多线程应用
• QoS Controller：标准化的服务质量控制器，替代当前临时方案
• 跨控制器协同：内存与 I/O 压力联动，自动调整策略达到最佳整体性能

随着 rootless 容器、云原生安全沙箱等场景的普及，cgroup v2 + eBPF 的组合将成为 Linux 资源管控的标准范式——掌握 cgroup v2 的核心机制和实战技巧，对于构建下一代云原生基础设施至关重要。