cgroups v1/v2资源限制与容器隔离

可视化演示

展示cgroups v1多控制器分散挂载与v2统一层级结构对比、资源限制CPU/内存/IO分配及与Namespace配合的容器隔离机制，分步演进理解核心原理。

核心概念：进程组的资源账本

合租公寓最头疼的是分配公共资源。管家 cgroups 的做法很简单：所有的租客不再各自单独找房东要水电，而是按“房间群”来记账。一个房间住了两个人，这两个人合成一组，共用一份电费额度。在 Linux 里，这个“房间群”就叫进程组，管家为每个组建立一个账本目录，组里的进程共同消耗这份配额。

把进程按组记账，还会形成天然的层次关系。厨房的用电和客厅的用电可以挂在大楼总账下，分出厨房小组、客厅小组。Linux 内核把这个层次做成了一棵倒挂的树：树的根是系统总资源，节点是子组，叶子挂着具体的进程。管理员想限制某个服务，只需往对应目录的配置文件中写入限额，就像房客在账单上签名承诺“我们屋本月最多用 100 度电”。

这种“分组 + 树 + 限额文件”的机制就是 cgroups 的核心形态。它由若干控制器（subsystem）组成，每个控制器负责一种资源——CPU、内存、IO、进程数。控制器像公寓里不同的表：电表、水表、煤气表各看各的。cgroups 负责让这些表协同工作：目录本身定义结构，写进文件的值定义限额，进程被放进目录就自动纳入限额。

合租公寓的类比收个尾：cgroups 成了公寓的管家，它手里只有一本账，账本上写了哪个门牌号（组）、哪些人（进程）、用了多少量（资源）。进程想搬家，只要改改目录里的归属即可；系统想暂停一家的权限，冻结这个目录即可。管理容器时，这套“账本”就是一切资源控制的基石。

资源控制器：分配资源的多块仪表

公寓管家要管四块仪表：电表管 CPU 时间，水表管内存容量，煤气表管磁盘 IO，还有一块“入住人数表”管进程数上限。这四个表在 cgroups 里就是四大核心控制器，各自负责不同资源，独立配置又相互配合。

先用 CPU 控制器讲清“分账”的思路。设在同一个空闲组里有两个房间 A 和 B，A 配置权重 200，B 配置权重 100。总时间片 300 份，A 拿走 2/3，B 拿走 1/3。权重不是绝对上限，而是按比例分饼——如果 B 没活干，A 可以吃到更多的空闲余量，这恰好对应合租时“谁先回来谁开空调”的弹性配额。

内存控制器就像公寓水表：memory.max 是一户人家的总用水上限，超过后系统会先回收缓存、压缩内存，实在不够就驱逐进程（OOM Kill）。IO 控制器则像限速阀——它可以规定某个目录每秒最多读写多少兆字节，防止下载任务把整栋楼的带宽吃光。PIDs 控制器管“最多能租几个人进去”：没有这个表，一个死循环进程可以无限 fork 出新进程，把系统挤爆，这相当于一间房住了千人。

四块表各司其职，但它们的配置在 v1 版本中散落在不同目录，管理起来相当混乱，也就引出了下一节要讲的多棵树问题。

v1 多层级：各自为政的多棵挂载树

早期版本（v1）里，每块表都自己独立记账：电表一本账、水表一本账、煤气表又一本账，而且每本账都从整栋楼开始重新画一棵树。公寓管家手里有 CPU、内存、IO 三棵互不相通的挂载树，同一个租客（进程）会同时出现在这三棵树里，各占一个节点。

目录结构上，v1 在 /sys/fs/cgroup/ 下为每个控制器单独建目录：cpu/、memory/、blkio/。一个进程在 CPU 树里属于“厨房组”，在内存树里却属于“客厅组”，两棵树之间没有任何关联。管理员想给某个服务统一限 CPU 和内存，必须分别在两个目录下创建同名子目录，配置量翻倍且容易漏。

v1 最痛的问题是协同困难。内存回收需要知道每个进程在 IO 树上的层级，而两棵树互不通信，导致写回（writeback）的 IO 无法正确归属到内存 cgroup，清理进程优先级也容易误判。从数学上看，协调代价随控制器数量组合爆炸：

除了协同困难，v1 的委托模型也受限：普通用户想把某棵子树“交给”容器运行时托管，需要逐棵树的目录都授权，且各控制器目录的挂载点分散在多个路径，容器引擎（如 Docker）创建容器时要写十几个文件、跨多个目录，一旦漏掉一个，资源限制就不完整。这些痛点直接催生了 v2 的“一本总账”设计。

v2 统一层级：一本总账的家族治理

v2 相当于房东换了一位新管家，把所有账本合并成一本总账，所有资源统一挂在同一个挂载点 /sys/fs/cgroup 下。不再出现“进程在 CPU 树的厨房组、内存树的客厅组”的分裂局面——每个进程在 v2 中只属于一个 cgroup 目录。

v2 的最关键设计是 no internal processes（不允许内部进程） 规则：树上的中间节点只做分组管理，不能直接装进程；进程必须被放到叶子节点。这就像大楼的分表必须挂在各层，不能所有房间的水费都记在楼顶总表上。这条规则保证了资源归属清晰，父组的统计值可以由子组精确求和。

委托模型也随之焕然一新。v2 提供 subtree_control 接口，容器运行时只要在某个子目录上声明“我要管理这个子树下的 CPU 和内存”，内核就把这棵子树的写入权委派给它。用户命名空间配合后，非 root 的容器引擎也能安心创建自己的 cgroup 子树，相当于管家把一整层楼的钥匙交给一个可信的二房东。

v2 的原子性也让回扣更有说服力：所有控制器写同一个目录下的文件，事务统一，告别“配置写了一半”的状态。有了统一的层级，内核还可以在此基础上做更精细的统计——这正为后面的 PSI 压力感知铺平了道路。

PSI压力感知：楼道里的压力传感器

当家是租出去了，可怎么知道楼道里的水电是不是已经快到极限了？PSI（Pressure Stall Information，压力停顿信息）就像装在各楼层的压力传感器，专门记录“资源不够用导致进程排队等待”的时间比例，而不是简单报告用过多少资源。

PSI 统计的是停顿：一个进程想要 CPU 却轮不到，想要内存却要等回收，想要 IO 却挤不进队列，这些等待时间都被记下来。内核以 10 秒、60 秒、300 秒三个窗口滚动平均，形成类似 load average 的曲线。它在 /proc/pressure/ 目录下分文件记录 CPU、内存、IO 三类压力值，每个文件都给出 some 和 full 两行指标：

对容器编排来说，PSI 的价值在于提前预警。在 v2 中，内核还会在 cgroup 目录里提供 cpu.pressure、memory.pressure、io.pressure 文件，指标细化到每个容器组。平台团队可以据此判断“这个 Pod 是 CPU hungry 还是 memory thrashing”，赶在 OOM 之前扩容或限制，而不用等到进程被杀。

eBPF辅助监控：装上透明摄像头

有了压力指标，还想看清房间里到底谁在搞鬼，这就轮到 eBPF 登场。eBPF 像帮管家在关键通道装上透明摄像头：不用改造公寓结构，也无打扰住户（不阻塞），就能看到每次进程进出 cgroup、每次资源限额变更的过程。

内核在 cgroup 的关键路径上预埋了 tracepoint（跟踪点），比如 cgroup_attach_task（进程加入某个组）、cgroup_release（进程离开组）、cgroup_rename（配置变更）。传统的监控方式需要不断去读文件、轮询比对；而 eBPF 程序直接挂在这些跟踪点旁边，事件一发生就被内核送出，开销低到几乎可以忽略。

eBPF 程序通过 map（数据地图）把事件聚合起来：以 cgroup id 为键，统计每个组创建了多少进程、切换了多少次 CPU、内存峰值多高。工具如 bpftrace 可以用几行脚本挂到上述 tracepoint 上；搭配 v2 稳定的 cgroup id，监控数据可以精确关联到容器 PID 与 Namespace：

eBPF 与 cgroups 的配合让监控从“看仪表”升级为“看监控录像”。平台可以在不改宿主机内核的情况下，铺开细粒度的资源审计和异常检测，这也是现代云原生可观测性产品（如 Cilium、Kindling）的核心技术手段。

与Namespace配合：门锁加账本

最后把整套容器隔离拼起来。cgroups 和 Namespace 分工极其明确：Namespace 决定进程“看得见什么”，cgroups 决定进程“用得到多少”。前者是公寓楼里给每户装独立门锁和窗帘——进程以为自己是楼里唯一的住户，看不到别的房间；后者是管家账本上写清楚每户的用电额度。

容器创建时，运行时（如 runc）先为进程创建一组 Namespace（PID、Network、Mount 等），让进程获得独立视图；紧接着在 /sys/fs/cgroup 下创建一个新的 cgroup 子树，把 CPU、内存、IO 限额写进对应文件，再把这个进程放入该组。两步合起来，容器就像一套带独立锁的“公寓内小公寓”，视图独立、资源受控，缺一不可：

容器的隔离边界也要讲清楚：cgroups 隔离不了内核共享数据，不能阻止进程读取宿主机的公开信息；Namespace 隔离不了资源消耗。所以生产环境中，容器逃逸防护通常要靠额外的安全机制（seccomp、Capabilities）补足——门锁和账本都只是公寓管理的一部分，而不是全部安保。

AI 应用场景

Python 演示

#!/usr/bin/env python3"""模拟 cgroups v1 与 v2 的 CPU 权重计算与层级委托差异。"""from dataclasses import dataclass, field  @dataclassclass Node:    name: str    weight: int = 100    children: list = field(default_factory=list)     def cpu_share_v2(self, siblings):        total = self.weight + sum(s.weight for s in siblings)        return self.weight / total     def insert(self, child):        self.children.append(child)  def build_v2_tree():    root = Node("root", weight=100)    online = Node("online", weight=200)    offline = Node("offline", weight=50)    root.insert(online)    root.insert(offline)    return root, online, offline  def build_v1_trees():    # v1 中 CPU 与 MEMORY 是两棵独立挂载树    cpu_tree = Node("cpu_root")    mem_tree = Node("mem_root")    cpu_proc = Node("proc_A", weight=150)    mem_proc = Node("proc_A", weight=100)    cpu_tree.insert(cpu_proc)    mem_tree.insert(mem_proc)    return cpu_tree, mem_tree  def main():    root, online, offline = build_v2_tree()    share_online = online.cpu_share_v2([offline])    print(f"v2: online 分得 {share_online:.2%} 的 CPU 饼")    print(f"v2: root 子节点数 = {len(root.children)}")     cpu_tree, mem_tree = build_v1_trees()    print(f"v1: 进程 proc_A 在 CPU 树权重 {cpu_tree.children[0].weight}")    print(f"v1: 进程 proc_A 在内存树权重 {mem_tree.children[0].weight}")    print("v1: 同一进程分别挂在两棵树上，配置需各写一次")  if __name__ == "__main__":    main()

1. class Node:用树节点表示一个 cgroup 目录，weight 对应 cpu.weight 配置。
2. def cpu_share_v2(self, siblings):按 v2 的权重比例计算 CPU 份额，实现公式 $\frac{\text{weight}}{\sum \text{weight}}$。
3. def build_v1_trees():构造两棵独立树，模拟 v1 中 CPU 与内存控制器分散挂载的情况。
4. print(f"v2: online 分得...")演示 v2 只需一次计算即可得结果，直观对比 v1 的多树一致性成本。

常见误区

面试题