cgroups v2 统一层级、控制器委派与 systemd 集成

可视化演示

基础演进：老物业的“一本台账”困局

老物业最头疼的是什么？账目分散。CPU、内存、IO 各有各的独立台账，d 每栋楼的住户要想被统一管理，得在各个部门分别登记。cgroups v1 就是这样：每个控制器（cpu、memory、blkio…）单独挂载一棵层级树，互不关联。

技术层面，v1 把 /sys/fs/cgroup/cpu、/sys/fs/cgroup/memory 等作为独立挂载点，每一棵树的目录结构可以完全不同。这带来两个致命伤：一是系统无法表达“同时按内存和 CPU 分组的进程集合”，因为组关系因资源而异；二是线程模型粗糙——向 tasks 文件写入线程组 ID 时会整体迁移所有线程，无法对单个线程做精细隔离。

cgroups v2 的设计目标因此非常明确：统一层级、安全委派、支持线程粒度。它把散落的“多本存折”合并成一张总账。

就像老小区每栋楼在自来水公司、电力公司、燃气公司各有一个户号，查一次总用量要跑三个窗口。v1 的架构在容器化早期够用，但随着多资源协同需求上升，它注定要被更统一的设计取代。

统一层级：一张总平面图管到底

新物业上任第一件事，就是把全小区画成一张总平面图。每栋楼、每个住户都在同一张图上登记，不再分部门建台账。cgroups v2 的核心正是这种“单树”设计：所有控制器共享一棵以 /sys/fs/cgroup 为根的层级树。

这棵树的规则非常清晰：根 cgroup 是所有进程的祖先；每个内部节点（目录）代表一个“组织单元”，叶子节点才允许直接挂进程。也就是说，一个目录如果有了子目录，就不能同时把 PID 写进 cgroup.procs，这被称为内部节点约束（no internal process constraint）。这样的约束保证了资源统计不会歧义——一个进程只属于一条从根到叶子的唯一路径。

写入规则也更精细了：cgroup.procs 接受进程 ID（整个线程组），cgroup.threads 接受线程 ID，并且支持线程模式（threaded mode），让某些子树可以按线程维度管理。你可以在总平面图上细分到“某个房间里的某张床”。

这就像总平面图上，一栋楼的“整层”可以再分成多家住户，但整层本身不能同时住人又分户。统一层级消除了 v1 多树带来的协调难题，让资源控制、统计、迁移都变得可预期。

控制器委派：把楼栋钥匙交给楼长

物业不可能替每个楼栋操心每盏灯、每台空调。合理的方式是：把整栋楼的水电表控制权打包，交给楼长，楼长在自己权限范围内安排住户配额。cgroups v2 的控制器委派（delegation）就是干这个的。

委派的开关在父目录的 subtree_control 文件里。父 cgroup 往这个文件写入 +cpu +memory，就表示允许子 cgroup 启用 CPU 和内存控制器。一旦写入，子 cgroup 的持有者（可以是普通非特权用户）就能在自己的子树里创建更深的 cgroup、调整控制文件数值，无需 root 权限。更关键的是，委派是“按控制器逐个授予”的：父级不给的控制器，子级就算写了 +io 也会被拒绝。

这套机制在容器运行时中极为重要：runc 启动容器时，会先创建一个空目录作为容器 cgroup，在父级写入 subtree_control 授予控制器，然后把容器的 init 进程放进这个子树。init 进程于是“接管”了这棵子树的管理权，容器内可以自由创建子 cgroup，但无法逃逸到父级去动别人的资源。

生活里，物业把整栋楼的灯闸交给楼长，但楼长无权打开小区总电房。委派在容器世界中的意义就是“最小权限”：让容器拥有内部自治能力，同时牢牢守住宿主资源的边界。

核心控制器：水表电表如何计量

有了总平面图和委派协议，接下来是计量工具。楼栋里的水表、电表、燃气表各有各的读数方式，cgroups v2 的核心控制器也各司其职。

CPU 调度靠两个文件配合：cpu.weight 决定竞争时的权重比例，类似“分时电表”——多个 cgroup 抢 CPU 时，谁的权重大谁拿到更多时间片；cpu.max 则规定硬性上限，格式是 quota/period，比如 100000/100000 表示最多用满 1 个核，50000/100000 表示最多用 0.5 个核。

内存管理通过 memory.max 和 memory.high 双阈值实现。memory.max 是硬墙，超过会触发 OOM 杀进程；memory.high 是软限，超过会开始回收页缓存，但不会立即杀人。这种“先警告后动手”的设计，让系统在压力下有缓冲空间。

IO 与网络方面，io.weight 控制块设备读写带宽的竞争比例（同样基于权重）；值得强调的是，v2 并不包含网络控制器，容器网络带宽一般通过 TC 或 eBPF 旁路实现，这也提醒我们：cgroup 并不是万能的“资源总闸”。

这些机制合起来，就像小区里既有点亮楼道灯的“分时电表”，也有防止爆管的“水压阀”——权重保证公平，配额保证上限，回收机制提供缓冲。

systemd 集成：物业公司与 ERP

有了计量工具，还需要一套物业管理系统把规则落地。systemd 在现代 Linux 发行版中扮演的正是这个角色：它把每个服务、用户会话都纳入统一的 cgroup 管理，形成“一个单元一棵子树”的格局。

systemd 的单元（unit）类型与 cgroup 路径有固定映射关系：.service 是一个服务，.scope 是一组临时进程，.slice 是资源分组容器，层层嵌套组成类似 .slice 路径的目录结构。配置层面，管理员可以在 unit 文件里直接写 CPUWeight=200、MemoryMax=2G、TasksMax=512 等指令，systemd 会自动把它们翻译成 cgroup 控制文件写入。例如设置 CPUWeight=200 后，systemd 会找到对应 cgroup 并写入 cpu.weight——你不需要碰任何内核接口。

更精彩的是委派实现：unit 里加一行 Delegate=yes，systemd 就会把这棵子树交给该服务自身管理，不会在服务结束后主动清理子树内容，也不会干预子树内部的 cgroup 操作。这正是容器运行时需要的——systemd 负责创建 Pod 的顶层 slice，runc 在 slice 下再创建容器 cgroup，两边各司其职。

systemd 对 cgroup v2 的深度集成，让“物业公司”有了真正的 ERP——管理员不再手动操作内核文件，而是通过熟悉的 unit 文件声明式管理资源。这也是为什么 Kubernetes 默认推荐 systemd cgroup driver：它保证宿主机服务、用户会话与容器各自拥有清晰的资源边界。

容器实践：智慧小区落地验收

图纸再漂亮，也要看实际交付。这一节我们看 cgroups v2 如何与容器运行时和运维体系配合，完成资源隔离的最后一公里。

首先是运行时配合。现代 Docker（20.10+）和 Kubernetes（1.22+）默认支持 cgroup v2。在 kubelet 配置 systemd cgroup driver 后，每个 Pod 会落到 kubepods slice 下，例如 /sys/fs/cgroup/kubepods.slice/kubepods-besteffort.slice/pod-xxx/，容器运行时再用 runc 在 Pod 目录下创建容器 cgroup 并写入资源限制。这套树状结构与 QoS 类别一一对应：Guaranteed 的 Pod 权重高、限制严格，Burstable 的 Pod 有弹性余量，BestEffort 则完全看运气。

运维配置上，systemd-run 是随手可用的利器。比如要对一个临时任务限流，可以执行 systemd-run --scope -p CPUWeight=10 -p MemoryMax=2G ./big_job，系统会为它创建一个 scope 并施加限制，任务结束自动清理。

排查故障时，重点观测三个文件：cpu.stat 里的 throttled_time 看出是否被限流，memory.events 里的 oom 计数判断是否被杀过，io.stat 追踪块设备读写。如果容器突然变慢且产生了大量 throttled_time，多半是 cpu.max 设得太紧；如果 memory.events 中 low 字段频繁增加，则是内存回收在持续挤压性能。

至此，“智慧小区”全部落地：统一层级让总平面图一目了然，控制器委派把钥匙交给楼长，核心控制器精确计量，systemd 提供自动化 ERP，容器实践则验证了整套体系在真实环境中的可靠性。

AI 应用场景

Python 演示

"""模拟 cgroup v2 CPU 时间片分配：权重比例 + 配额上限"""from dataclasses import dataclassfrom typing import List  @dataclassclass CGroup:    name: str    weight: int    quota: int = 100000  # cpu.max quota，单位 us    period: int = 100000  # cpu.max period，单位 us  def weighted_share(groups: List[CGroup]) -> dict:    """按 cpu.weight 计算竞争状态下的时间片占比"""    total = sum(g.weight for g in groups)    return {g.name: g.weight / total for g in groups}  def hard_limit(g: CGroup) -> float:    """cpu.max = quota/period 决定的 CPU 核数上限"""    return g.quota / g.period  if __name__ == "__main__":    online = CGroup("online", weight=800, quota=1600000, period=100000)    batch = CGroup("batch", weight=150, quota=600000, period=100000)    test = CGroup("test", weight=50, quota=200000, period=100000)    groups = [online, batch, test]     print("=== CPU 竞争时间片占比(权重) ===")    for name, ratio in weighted_share(groups).items():        print(f"  {name:<8} {ratio:.1%}")     print("\n=== CPU 硬性上限(cpu.max) ===")    for g in groups:        print(f"  {g.name:<8} {hard_limit(g):.2f} 核")

1. class CGroup定义了一个数据中心的数据类，weight 对应 cpu.weight，quota/period 对应 cpu.max。
2. weighted_share(groups)复现了正文公式 $S_i = w_i / \sum w_j$，计算每个 cgroup 的竞争份额。
3. total = sum(g.weight for g in groups)求所有权重总和作为分母，权重是相对值这一点在这里体现得最直观。
4. hard_limit(g)直接返回 quota/period 的结果，对应“最多占多少核”。
5. CGroup("online", weight=800, ...)模拟在线服务高权重，让它拿到绝大多数的竞争份额。
6. print(f" {name:<8} {ratio:.1%}")用格式化输出展示分配结果，<8 左对齐让表格更整齐。

常见误区

面试题