【Docker 内核详解】cgroups 资源限制（三）：实现方式及工作原理简介

在对 cgroups 规则和子系统有了一定了解以后，下面简单介绍操作系统内核级别上 cgroups 的工作原理，希望能有助于大家理解 cgroups 如何对 Docker 容器中的进程产生作用。cgroups 的实现本质上是 给任务挂上钩子，当任务运行的过程中涉及某种资源时，就会触发钩子上所附带的子系统进行检测，根据资源类别的不同，使用对应的技术进行资源限制和优先级分配。

1.cgroups 如何判断资源超限及超出限额之后的措施

对于不同的系统资源，cgroups 提供了统一的接口对资源进行控制和统计，但限制的具体方式则不尽相同。比如 memory 子系统，会在描述内存状态的 mm_struct 结构体中记录它所属的 cgroup，当进程需要申请更多内存时，就会触发 cgroup 用量检测，用量超过 cgroup 规定的限额，则拒绝用户的内存申请，否则就给予相应内存并在 cgroup 的统计信息中记录。实际实现要比以上描述复杂得多，不仅需考虑内存的分配与回收，还需考虑不同类型的内存如 cache（缓存）和 swap（交换区内存拓展）等。

进程所需的内存超过它所属的 cgroup 最大限额以后，如果设置了 OOM Control（内存超限控制），那么进程就会收到 OOM 信号并结束；否则进程就会被挂起，进入睡眠状态，直到 cgroup 中其他进程释放了足够的内存资源为止。Docker 中默认是开启 OOM Control 的。其他子系统的实现与此类似，cgroups 提供了多种资源限制的策略供用户选择。

2.cgroup 与任务之间的关联关系

实现上，cgroup 与任务之间是多对多的关系，所以它们并不直接关联，而是通过一个 中间结构 把双向的关联信息记录起来。每个任务结构体 task_struct 中都包含了一个指针，可以查询到对应 cgroup 的情况，同时也可以查询到各个子系统的状态，这些子系统状态中也包含了找到任务的指针，不同类型的子系统按需定义本身的控制信息结构体，最终在自定义的结构体中把子系统状态指针包含进去，然后内核通过 container_of（这个宏可以通过一个结构体的成员找到结构体自身）等宏定义来获取对应的结构体，关联到任务，以此达到资源限制的目的。

同时，为了让 cgroups 便于用户理解和使用，也为了用精简的内核代码为 cgroup 提供熟悉的权限和命名空间管理，内核开发者们按照 Linux 虚拟文件系统转换器（Virtual Filesystem Switch，VFS）接口实现了一套名为 cgroup 的文件系统，非常巧妙地用来表示 cgroups 的层级概念，把各个子系统的实现都封装到文件系统的各项操作中。大家有兴趣可以查阅 VFS 的相关内容，在此就不赘述了。

3.Docker 在使用 cgroup 时的注意事项

在实际的使用过程中，Docker 需要通过挂载 cgroup 文件系统新建一个层级结构，挂载时指定要绑定的子系统。把 cgroup 文件系统挂载上以后，就可以像操作文件一样对 cgroups 的层级进行浏览和操作管理（包括权限管理、子文件管理等）。除了 cgroup 文件系统以外，内核没有为 cgroups 的访问和操作添加任何系统调用。

如果新建的层级结构要绑定的子系统与目前已经存在的层级结构完全相同，那么新的挂载会重用原来已经存在的那一套（指向相同的 css_set）。否则，如果要绑定的子系统已经被别的层级绑定，就会返回挂载失败的错误。如果一切顺利，挂载完成后层级就被激活并与相应子系统关联起来，可以开始使用了。

目前无法将一个新的子系统绑定到激活的层级上，或者从一个激活的层级中解除某个子系统的绑定。

当一个顶层的 cgroup 文件系统被卸载（umount）时，如果其中创建过深层次的后代 cgroup 目录，那么就算上层的 cgroup 被卸载了，层级也是激活状态，其后代 cgroup 中的配置依旧有效。只有递归式地卸载层级中的所有 cgroup，那个层级才会被真正删除。在创建的层级中创建文件夹，就类似于 fork 了一个后代 cgroup，后代 cgroup 中默认继承原有 cgroup 中的配置属性，但是可以根据需求对配置参数进行调整。这样就把一个大的 cgroup 系统分割成一个个嵌套的、可动态变化的 “软分区”。

4./sys/fs/cgroup/cpu/docker/[container-ID] 下文件的作用

前面已经说过，以资源开头（比如 cpu.shares）的文件都是用来限制这个 cgroup 下任务的可用的配置文件。一个 cgroup 创建完成，不管绑定了何种子系统，其目录下都会生成以下几个文件，用来描述 cgroup 的相应信息。同样，把相应信息写入这些配置文件就可以生效，内容如下。

• tasks：这个文件中罗列了所有在该 cgroup 中任务的 TID，即所有进程或线程的 ID。该文件并不保证任务的 TID 有序，把一个任务的 TID 写到这个文件中就意味着把这个任务加入这个 cgroup 中，如果这个任务所在的任务组与其不在同一个 cgroup，那么会在 cgroup.procs 文件里记录一个该任务所在任务组的 TGID 值，但是该任务组的其他任务并不受影响。
• cgroup.procs：这个文件罗列所有在该 cgroup 中的 TGID（线程组 ID），即线程组中第一个进程的 PID。该文件并不保证 TGID 有序和无重复。写一个 TGID 到这个文件就意味着把与其相关的线程都加到这个 cgroup 中。
• notify_on_release：填 $0$ 或 $1$，表示是否在 cgroup 中最后一个任务退出时通知运行 release agent，默认情况下是 $0$，表示不运行。
• release_agent：指定 release agent 执行脚本的文件路径（该文件在最顶层 cgroup 目录中存在），这个脚本通常用于自动化卸载无用的 cgroup。

---

本系列由浅入深地讲解了 cgroups，从 cgroups 是什么，到 cgroups 该怎么用，最后对大量的 cgroup 子系统配置参数进行了梳理。可以看到，内核对 cgroups 的支持已经较多，但是依旧有许多工作需要完善。如网络方面目前通过 TC（Traffic Controller）来控制，未来需要统一整合；优先级调度方面依旧有很大的改进空间。