【Docker 内核详解】cgroups 资源限制（二）：组织结构与基本规则、子系统简介

1.组织结构与基本规则

在之前的博客已经介绍过，传统的 Unix 任务管理，实际上是先启动 init 任务作为根节点，再由 init 节点创建子任务作为子节点，而每个子节点又可以创建新的子节点，如此往复，形成一个树状结构。而系统中的多个 cgroup 也构成类似的树状结构，子节点从父节点继承属性。

它们最大的不同在于，系统中的多个 cgroup 构成的层级并非单根结构，可以允许存在多个。如果任务模型是由 init 作为根节点构成的一棵树，那么系统中的多个 cgroup 则是由多个层级构成的森林。这样做的目的很好理解，如果只有一个层级，那么所有的任务都将被迫绑定其上的所有子系统，这会给某些任务造成不必要的限制。在 Docker 中，每个子系统独自构成一个层级，这样做非常易于管理。

了解了 cgroups 的组织结构，再来了解 cgroups、任务、子系统、层级四者间的关系及其基本规则。

规则 1：同一个层级可以附加一个或多个子系统。如下图所示，CPU 和 Memory 的子系统附加到了一个层级。

规则 2：一个子系统可以附加到多个层级，当且仅当目标层级只有唯一一个子系统时。下图中小圈中的数字表示子系统附加的时间顺序，CPU 子系统附加到层级 A 的同时不能再附加到层级 B，因为层级 B 已经附加了内存子系统。如果层级 B 没有附加过内存子系统，那么 CPU 子系统同时附加到两个层级是允许的。

规则 3：系统每次新建一个层级时，该系统上的所有任务默认加入这个新建层级的初始化 cgroup，这个 cgroup 也被称为 root cgroup。对于创建的每个层级，任务只能存在于其中一个 cgroup 中，即一个任务不能存在于同一个层级的不同 cgroup 中，但一个任务可以存在于不同层级中的多个 cgroup 中。如果操作时把一个任务添加到同一个层级中的另一个 cgroup 中，则会将它从第一个 cgroup 中移除。在下图中可以看到，httpd 任务已经加入到层级 A 中的 /cg1，而不能加入同一个层级中的 /cg2，但是可以加入层级 B 中的 /cg3。

规则 4：任务在 fork/clone 自身时创建的子任务默认与原任务在同一个 cgroup 中，但是子任务允许被移动到不同的 cgroup 中。即 fork/clone 完成后，父子任务间在 cgroup 方面是互不影响的。下图中小圈中的数字表示任务出现的时间顺序，当 httpd 刚 fork 出另一个 httpd 时，两者在同一个层级中的同一个 cgroup 中。但是随后如果 ID 为 4840 的 httpd 需要移动到其他 cgroup 也是可以的，因为父子任务间已经独立。总结起来就是：初始化时子任务与父任务在同一个 cgroup，但是这种关系随后可以改变。

2.子系统简介

子系统实际上就是 cgroups 的资源控制系统，每种子系统独立地控制一种资源，目前 Docker 使用如下 9 种子系统，其中，net_cls 子系统在内核中已经广泛实现，但是 Docker 尚未采用，Docker 在网络方面的控制方式将在后续详细介绍，以下是它们的用途。

• blkio：可以为块设备设定输入 / 输出限制，比如物理驱动设备（包括磁盘、固态硬盘、USB 等）。
• cpu：使用调度程序控制任务对 CPU 的使用。
• cpuacct：自动生成 cgroup 中任务对 CPU 资源使用情况的报告。
• cpuset：可以为 cgroup 中的任务分配独立的 CPU（此处针对多处理器系统）和内存。
• devices：可以开启或关闭 cgroup 中任务对设备的访问。
• freezer：可以挂起或恢复 cgroup 中的任务。
• memory：可以设定 cgroup 中任务对内存使用量的限定，并且自动生成这些任务对内存资源使用情况的报告。
• perf _event：使用后使 cgroup 中的任务可以进行统一的性能测试。
• net_cls：Docker 没有直接使用它，它通过使用等级识别符（classid）标记网络数据包，从而允许 Linux 流量控制程序（Traffic Controller，TC）识别从具体 cgroup 中生成的数据包。

上述子系统如何使用虽然很重要，但是 Docker 并没有对 cgroup 本身做增强，容器用户一般也不需要直接操作 cgroup，所以这里我们只大致说明一下操作流程，让大家有一个感性的认识。

Linux 中 cgroup 的实现形式表现为一个文件系统，因此需要 mount 这个文件系统才能够使用（也有可能已经 mount 好了），挂载成功后，就能看到各类子系统。

以 cpu 子系统为例，先看一下挂载了这个子系统的控制组下的文件。

在 /sys/fs/cgroup 的 cpu 子目录下创建控制组，控制组目录创建成后，它下面就会有很多类似的文件了。

下面的例子展示了如何限制 PID 为 18828 的进程的 cpu 使用配额：

> 和 >> 其实都属于输出重定向，都可以输出内容到指定文件。

• > 会覆盖目标的原有内容，当文件存在时，会先删除原文件，再重新创建文件，然后把内容写入该文件（即清空了原文件），否则直接创建文件。
• >> 会在目标原有内容后追加内容，当文件存在时直接在文件末尾进行内容追加，不会删除原文件，否则直接创建文件。

在 Docker 的实现中，Docker daemon 会在单独挂载了每一个子系统的控制组目录（比如 /sys/fs/cgroup/cpu）下创建一个名为 docker 的控制组，然后在 docker 控制组里面，再为每个容器创建一个以容器 ID 为名称的容器控制组，这个容器里的所有进程的进程号都会写到该控制组 tasks 中，并且在控制文件（比如 cpu.cfs_quota_us）中写入预设的限制参数值。综上，docker 组的层级结构如下。

关于 Docker 如何实现 cgroup 的配置的问题，将会在后续有关 libcontainer 的博客里解释。