Linux内核Cgroup资源隔离实战：容器化场景下的CPU与内存管理

深入理解Linux Cgroup v1/v2架构，掌握容器资源隔离的底层机制

摘要

Control Group（Cgroup）是Linux内核提供的一种限制、记录和隔离进程组资源使用的机制。它是Docker、Kubernetes等容器技术的底层基石。本文深入剖析Cgroup的架构设计、v1到v2的演进，并结合实战案例讲解CPU、内存、I/O子系统的精细控制策略。

一、Cgroup架构总览

Cgroup的核心思想是将进程分组，并为每组分配资源配额。其架构包含三个核心组件：

• Hierarchy（层级树）：Cgroup的组织方式，类似文件系统的目录结构，进程可以附加到叶子节点
• Subsystem（子系统/Resource Controller）：具体的资源控制器，如cpu、memory、blkio等
• Control Group：由task（进程）+ 一组资源控制参数构成的实体

在Cgroup v1中，各个子系统可以挂载到独立的hierarchy，这带来了碎片化管理问题。Cgroup v2统一了hierarchy，要求所有子系统协同工作，解决了v1的诸多设计缺陷。

mount -t cgroup2 none /sys/fs/cgroup 即可挂载v2 filesystem。

二、CPU子系统：从份额限制到精确控制

2.1 CFS带宽控制（cpu.max）

Cgroup v2的cpu.max使用"period/quota"双参数模型：

# 限制容器最多使用 0.5 个 CPU
echo "50000 100000" > /sys/fs/cgroup/mycontainer/cpu.max

# 允许最多使用 2 个 CPU（多核场景）
echo "200000 100000" > /sys/fs/cgroup/mycontainer/cpu.max

含义：每个100000微秒（100ms）的周期内，允许使用50000微秒（50ms）的CPU时间，即0.5核。当进程消耗完quota后，CFS调度器会将该cgroup中的进程throttle，直到下一个period。

2.2 实时调度策略（cpu.weight）

对于需要实时性的场景，Cgroup v2提供了cpu.weight（默认100，范围1-10000），基于(parent_weight / 子cgroup_weight之和)的比例分配：

# 高优先级容器获取更多CPU时间
echo "500" > /sys/fs/cgroup/high_priority/cpu.weight
echo "100" > /sys/fs/cgroup/normal_priority/cpu.weight

高优先级容器将获得5倍于普通容器的CPU份额。

2.3 CPU亲和性与cpuset

# 将容器限制在核心0-3上运行
echo "0-3" > /sys/fs/cgroup/mycontainer/cpuset.cpus
echo "0" > /sys/fs/cgroup/mycontainer/cpuset.mems

cpuset在大NUMA系统上特别重要，不当的跨节点访问会导致内存延迟翻倍。

三、内存子系统：硬限制与软限制的平衡艺术

3.1 内存硬限制（memory.max）

• 进程尝试分配超过memory.max时触发OOM Killer
• OOM选择策略由oom_score_adj控制，数值越高越容易被kill
• echo "536870912" > memory.max 限制为512MB

3.2 内存软限制与压力监控

memory.low是"尽力而为"的保护阈值：当系统总体内存紧张时，内核尽力保证该cgroup至少拥有memory.low数量的内存不被回收。这对于设置缓存层容器非常有用。

memory.high则是主动回收的触发线，内核在该cgroup使用量超过high时启动回收（而非等到max触发OOM），给应用一个优雅降级的时间窗口。

3.3 实战：数据库容器的内存配置

# 数据库容器推荐配置
echo "8G" > /sysfs/cgroup/db/memory.max        # 硬上限8GB
echo "6G" > /sys/fs/cgroup/db/memory.low       # 尽力保证至少6GB
echo "7G" > /sys/fs/cgroup/db/memory.high      # 超过7GB触发后台回收
echo "2G" > /sys/fs/cgroup/db/memory.swap.max  # 限制swap为2GB

这种"阶梯式"配置让数据库在内存压力下graceful degradation，避免了突然OOM导致的连接断开。

四、I/O子系统：带宽与IOPS的双维度控制

4.1 带宽限制（io.max）

# 限制设备 /dev/sda: 读100MB/s, 写50MB/s
echo "rbps=104857600 wbps=52428800" > /sys/fs/cgroup/app/io.max

42. IOPS限制

# 限制读IOPS为1000，写IOPS为500
echo "riops=1000 wiops=500" > /sys/fs/cgroup/app/io.max

4.3 io.weight权重分配

类似CPU的io.weight（默认100，范围1-10000），按比例分配I/O带宽。这对于混合部署（日志写入 + 数据库读写 + 备份任务）特别有效。

五、Cgroup v2新特性详解

5.1 统一层级树

v2消除了v1中各子系统独立mount的混乱，所有控制器挂载在同一个层级下，使得资源分配决策可以全局协调。

5.2 Pressure Stall Information (PSI)

v2内置的PSI接口可以监控资源争抢导致的排队延迟：

cat /sys/fs/cgroup/app/cpu.pressure
# some avg10=0.00 avg60=0.00 avg300=0.00 total=0

cat /sys/fs/cgroup/app/memory.pressure
# some avg10=15.23 avg60=8.45 avg300=2.11 total=9876543210

avg10/60/300分别代表过去10秒、60秒、300秒内被阻塞的CPU时间占比。这个指标比单纯的CPU使用率更能反映真实的资源争抢情况。

5.3 eBPF深度集成

Cgroup v2与eBPF形成了完美协同——eBPF程序可以attach到cgroup级别的hook点上（如cgroup_skb、cgroup_sock_addr），实现精确到进程组级别的网络策略执行。

六、Kubernetes中的Cgroup映射

Kubernetes的Resource Requests/Limits直接映射到Cgroup参数：

resources:
  requests:
    cpu: "500m"       # → cpu.weight ≈ 19 (v1 equivalent: cpu.shares)
    memory: "256Mi"   # → memory.low = 256Mi
  limits:
    cpu: "2"          # → cpu.max = "200000 100000"
    memory: "512Mi"   # → memory.max = 512Mi

值得注意的是：Kubernetes的memory.requests并非映射memory.low（某些独立发行版或自定义kubelet可以配置），而是影响调度决策。containerd/runc在创建容器时会按照OCI spec设置cgroup参数。

七、生产环境最佳实践

7.1 设置根cgroup默认限制

mkdir -p /sys/fs/cgroup/system-reserved
echo "1G" > /sys/fs/cgroup/system-reserved/memory.max
echo "50000 100000" > /sys/fs/cgroup/system-reserved/cpu.max

# 将systemd关键服务移入保留cgroup
for pid in $(systemctl show --property MainPID --value journald sshd); do
  [ "$pid" -gt 0 ] && echo "$pid" > /sys/fs/cgroup/system-reserved/cgroup.procs
done

7.2 容器逃逸防护

在共享内核的容器环境中，Cgroup本身是隔离辅助手段，不是边界。应配合seccomp、AppArmor/SELinux、Capability drop使用。

7.3 监控与告警

• 监控memory.usage_in_bytes接近memory.max的频率（预测OOM风险）
• cpu.pressure avg10 > 10% 触发资源紧张告警
• io.pressure持续升高预示存储瓶颈

八、总结

Cgroup作为容器化世界的基石，其v2版本通过统一层级、PSI压力监控、更清晰的API设计，为云原生基础设施提供了坚实的资源隔离保障。理解Cgroup的底层机制，是每一个平台工程师不可或缺的"内功"——当容器出现不可解释的卡顿或OOM时，能直接通过cgroup文件系统快速定位问题的工程师，才是真正的"内核高手"。

参考资料

• kernel Documentation: admin-guide/cgroup-v2.rst
• Linux source: kernel/cgroup/ 源码分析
• OCI Runtime Spec — Linux Container Configuration