容器原理之cgroup

“以 docker 为代表，轻量、便携的 container 使得打包和发布应用非常容易。系列文章容器原理主要分析 container 用到的核心技术，主要包括 Linux namespace，cgroups，overlayfs，看完这些内容，你将可以手动创建一个和 container 类似的环境。

cgroup（control group）是一个内核特性，用于限制、统计、隔离一组进程的资源（CPU、内存、磁盘、网络等），首字母不要大写。

““cgroup” stands for “control group” and is never capitalized.

• 单数形式（cgroup）指所有特性，也可以作为“cgroup controllers”的修饰。
• 复数形式（cgroups）指多个 cgroup。

Google 工程师在 2006 年开始提出这个特性，最早叫“process containers”，为了避免造成歧义，在 2007 年改名为“control group”，在 2008 年 1 月发布的 Linux Kernel 2.6.24 合入主线分支。此后，在此基础上又增加了一系列特性，包括 kernfs（伪文件系统，用于向用户导出内核的设备模型），firewalling（基于预定义的安全规则管理网络流量）和 unified hierarchy。在 Linux Kernel 4.5 版本合入了 cgroup v2 的实现代码。

cgroup 功能

在云原生场景下，可以通过 cgroups 限制每个容器可以使用的资源。例如，对于 kubernetes，可以用于决定是否调度 pod 到某个节点，从而确保每个容器中的应用都有足够的可用资源。

cgroup 主要功能包括：

• 资源限制：限制一组进程的可用资源阈值。
• 资源监控：监控 cgroup 级别的资源使用状态。
• 进程控制：控制（挂起 or 恢复）cgroup 中的所有进程。
• 优先级控制：控制不同 cgroup 的优先级，当资源不足时，优先满足优先级高的 cgroup。

cgroup 模式

目前，cgroups 有两个版本，cgroup V1 和 cgroup V2。V1 功能相对零散，不方便维护，V2 是未来的演进方向。在这种情况下，节点存在以下面 3 种 cgroups 模式：

• legacy：只支持 cgroup V1
• hybrid：同时支持 cgroup V1 和 cgroup V2
• unified：只支持 cgroup V2

在 containerd 中，通过以下方式判断处于哪种模式：

const unifiedMountpoint = "/sys/fs/cgroup"

// Mode returns the cgroups mode running on the host
func Mode() CGMode {
    checkMode.Do(func() {
        var st unix.Statfs_t
        // 没挂载 /sys/fs/cgroup
        if err := unix.Statfs(unifiedMountpoint, &st); err != nil {
            cgMode = Unavailable
            return
        }
        switch st.Type {
        case unix.CGROUP2_SUPER_MAGIC:
            // /sys/fs/cgroup 挂载为 cgroup2 文件系统格式
            cgMode = Unified
        default:
            cgMode = Legacy
            if err := unix.Statfs(filepath.Join(unifiedMountpoint, "unified"), &st); err != nil {
                return
            }
            // /sys/fs/cgroup/unified 挂载为 cgroup2 文件系统格式
            if st.Type == unix.CGROUP2_SUPER_MAGIC {
                cgMode = Hybrid
            }
        }
    })
    return cgMode
}

• Cgroup

也可以通过以下命令判断：

[ $(stat -fc %T /sys/fs/cgroup/) = "cgroup2fs" ] && echo "unified" || ( [ -e \
/sys/fs/cgroup/unified/ ] && echo "hybrid" || echo "legacy")

通过 Linux 启动参数修改 cgroups 模式。例如，使用 unified 模式（注意cgroup_no_v1=all）：

GRUB_CMDLINE_LINUX="cgroup_enable=memory systemd.unified_cgroup_hierarchy=1 \
systemd.legacy_systemd_cgroup_controller=0 cgroup_no_v1=all"

使用 legacy 模式：

GRUB_CMDLINE_LINUX="cgroup_enable=memory systemd.unified_cgroup_hierarchy=0 \
systemd.legacy_systemd_cgroup_controller=1"

使用 hybrid 模式：

GRUB_CMDLINE_LINUX="cgroup_enable=memory systemd.unified_cgroup_hierarchy=1 \
systemd.legacy_systemd_cgroup_controller=1"

cgroup V1

基本概念

cgroup v1 主要包括以下几个概念：

• subsystem（子系统）：内核模块，具体的资源控制器，可以被关联到 cgroup 树。不同资源的控制器不同，例如，内存子系统控制内存资源，CPU 子系统控制 CPU 资源。
• cgroup（控制组）：资源隔离的最小单位，表示一组进程和 cgroup 子系统的关联，例如：通过内存子系统限制一组进程的可用内存资源总量。进程可以加入某个 cgroup，也可以从一个 cgroup 迁移到另一个 cgroup，同一进程不能同时存在同类型的两个 cgroup 中。
• hierarchy（层级）：由一系列 cgroup 按照树状结构排列，每个节点都是一个 cgroup，子 cgroup 默认继承父 cgroup 的参数和配置。系统可以有多个层级（cgroup 树），每个层级可以和不同的 subsystem 关联，每个 subsystem 只能和一个层级关联，同一进程可以属于多个层级，但在每个层级中只能属于一个 cgroup 节点。

cgroup 类型（subsystem）

cgroup V1 支持的资源类型如下：

? ls -l /sys/fs/cgroup
total 0
dr-xr-xr-x  9 root root  0 Jun 12 20:56 blkio
lrwxrwxrwx  1 root root 11 Jun 12 20:56 cpu -> cpu,cpuacct
lrwxrwxrwx  1 root root 11 Jun 12 20:56 cpuacct -> cpu,cpuacct
dr-xr-xr-x 10 root root  0 Jun 12 20:56 cpu,cpuacct
dr-xr-xr-x  7 root root  0 Jun 12 20:56 cpuset
dr-xr-xr-x  9 root root  0 Jun 12 20:56 devices
dr-xr-xr-x  7 root root  0 Jun 12 20:56 freezer
dr-xr-xr-x  6 root root  0 Jun 12 20:56 hugetlb
dr-xr-xr-x 10 root root  0 Jun 12 20:56 memory
lrwxrwxrwx  1 root root 16 Jun 12 20:56 net_cls -> net_cls,net_prio
dr-xr-xr-x  7 root root  0 Jun 12 20:56 net_cls,net_prio
lrwxrwxrwx  1 root root 16 Jun 12 20:56 net_prio -> net_cls,net_prio
dr-xr-xr-x  7 root root  0 Jun 12 20:56 perf_event
dr-xr-xr-x  9 root root  0 Jun 12 20:56 pids
dr-xr-xr-x 10 root root  0 Jun 12 20:56 systemd

• blkio：限制块设备的 IO
• cpu：通过调度程序控制可用 CPU 资源总量
• cpuacct：CPU 资源的使用情况
• cpuset：控制进程可用的 CPU 和内存
• devices：控制对设备的访问
• freezer：挂起或恢复 cgroup 中的进程
• hugetlb：控制进程可用的大页内存
• memory：控制进程可用的内存总量，同时统计内存使用情况
• net_cls：将 cgroup 中的网络包分类
• net_prio：控制网络流量的优先级
• perf_event：监控 cgroup 的性能
• pids：控制可创建的进程总数

Cgroup 子系统运行在内核态，不能直接和用户交互，因此，需要通过文件系统提供和终端用户的接口。在 Linux 中，表现为 Cgroup 子系统挂载的文件系统目录，用户操作这些文件就可以直接和内核中的 Cgroup 对象交互。

不同的子系统对应的文件系统目录包含不同的文件，但以下文件是所有子系统都有的：

cgroup.clone_children
cgroup.procs
notify_on_release
tasks

• cgroup.clone_children

控制子 cgroup 是否继承父 cgroup 的配置，只对 cpuset 子系统有效，并且在 cgroup V2 中已经移除。

• cgroup.procs

位于当前 cgroup 的 TGID（线程组 ID），TGID 是进程组中第一个进程的 PID。该文件是可写的，向该文件写入 TGID 即将对应线程组加入 cgroup，不保证文件中的 TGID 有序和不重复。

• tasks

位于当前 cgroup 中 task 的 TID（线程 ID），即进程组中的所有线程的 ID。该文件是可写的，将任务的 TID 写入这个文件表示将其加入对应 cgroup，如果该任务的 TGID 在另一个 cgroup，会在 cgroup.procs 记录该任务的 TGID，进程组中的其它 task 不受影响。不保证文件中的 TID 有序和不重复。

?? 注意：如果向 cgroup.procs 写入 TGID，系统会自动更新 tasks 文件中的内容为该线程组中所有任务的 TID。

> cat cgroup.procs
> cat tasks
> echo 40790 > cgroup.procs
> cat tasks
40791
40792
40793
40794
40795

向 tasks 文件中写入 TID，cgroup.procs 中的值也会更新为对应 TGID，但是并不影响该线程组中的其它任务。

> echo 45345 > tasks
> cat cgroup.procs
45340
> cat tasks
45345

• notify_on_release

是否开启 release agent，如果该文件中的值为 1，当 cgroup 中不包含任何 task 时（tasks 中的 TID 被全部移除），kernel 会执行 release_agent 文件（位于 root cgroup 的 release_agent 文件，例如/sys/fs/cgroup/memory/release_agent）的内容。所有非 root cgroup 从父 cgroup 继承该值。

cgroup V2

基本概念

在 cgroup v2 中，去掉了层级（hierarchy）的概念，只有一个层级，所有 cgroup 在该层级中以树形的方式组织，每个 cgroup 可以管理多种资源。

cgroup v2 不需要单独挂载每个子系统。

? findmnt -R /sys/fs/cgroup
TARGET         SOURCE  FSTYPE  OPTIONS
/sys/fs/cgroup cgroup2 cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate

如何查看 cgroup 开启了哪些 controller（和 cgroup v1 子系统的概念类似）呢？在 cgroup v2 中，每个 cgroup 目录下有个名为cgroup.controllers的可读文件，记录了当前 cgroup 启用的 controller。根目录下cgroup.controllers文件的内容记录了当前系统支持的所有 controller。

? cat cgroup.controllers
cpuset cpu io memory pids

新建子 cgroup 时，cgroup.controllers 继承父 cgroup 的?cgroup.subtree_control?值，子 cgroup 的?cgroup.subtree_control为空，表示在该子 cgroup 下再次创建子 cgroup 时，默认不会启用 controller。

创建一个testcgroup，此时，cgroup.subtree_control的值为空：

? pwd
/sys/fs/cgroup
? mkdir test
? cat cgroup.subtree_control

cgroup.controllers的值和父 cgroup 的cgroup.subtree_control值相同：

# 父 cgroup 的 cgroup.subtree_control
? cat cgroup.subtree_control
cpuset cpu io memory pids

# test cgroup 的 cgroup.controllers
? cat test/cgroup.controllers
cpuset cpu io memory pids

在test下再创建一个子 cgroup?child，此时，child的cgroup.controllers的内容为空：

? mkdir test/child
? cat test/child/cgroup.controllers

子 cgroup?child中的文件：

cgroup.controllers  cgroup.max.descendants  cgroup.threads  io.pressure
cgroup.events       cgroup.procs            cgroup.type     memory.pressure
cgroup.freeze       cgroup.stat             cpu.pressure
cgroup.max.depth    cgroup.subtree_control  cpu.stat

修改父 cgroup 的 cgroup.subtree_control，增加 cgroup controller：

? echo "+memory" > test/cgroup.subtree_control
? cat test/child/cgroup.controllers
memory

1. 与此同时，子 cgroup?child中增加了 memory 相关的文件：

? ls test/child
cgroup.controllers      cpu.stat             memory.oom.group
cgroup.events           io.pressure          memory.pressure
cgroup.freeze           memory.current       memory.reclaim
cgroup.max.depth        memory.drop_cache    memory.stat
cgroup.max.descendants  memory.events        memory.swap.current
cgroup.procs            memory.events.local  memory.swap.events
cgroup.stat             memory.high          memory.swap.max
cgroup.subtree_control  memory.low
cgroup.threads          memory.max
cgroup.type             memory.min
cpu.pressure            memory.numa_stat

删除子 cgroup 中的 controller，也通过修改父 cgroup 的cgroup.subtree_control实现：

? echo "-memory" > test/cgroup.subtree_control
? cat test/child/cgroup.controllers

对一个 cgroup，如果?cgroup.procs的值不为空，不能设置?cgroup.subtree_control的值。

? cat cgroup.procs
49347
? echo "+memory" > cgroup.subtree_control
echo: write error: device or resource busy

此时，需要将 cgroup 中的进程移动到其它子 cgroup，确保当前 cgroup 中cgroup.procs的值为空：

? mkdir tmp
? echo 49347 > tmp/cgroup.procs
? echo "+memory" > cgroup.subtree_control
? cat child/cgroup.controllers
memory

未开启任何 controller 时，cgroup 中包含以下文件：

? ls test/child
cgroup.controllers
cgroup.events
cgroup.freeze
cgroup.max.depth
cgroup.max.descendants
cgroup.procs
cgroup.stat
cgroup.subtree_control
cgroup.threads
cgroup.type
cpu.pressure
cpu.stat
io.pressure
memory.pressure

• cgroup.controllers：当前 cgroup 开启的 controller 列表。
• cgroup.events：存在于非 root cgroup 中，包括两个字段：populated 和 frozen。

? cat cgroup.events
populated 0
frozen 0

populated：如果当前 cgroup 和子层级中没有存活的进程，populated 值为 0，否则为 1。值改变时会触发 poll 和 notify 事件。考虑以下 cgroup 层级（括号中的数字代表 cgroup 中的进程数量）：

A(4) - B(0) - C(1)
            \ D(0)

A，B 和 C 的 populated 值都为 1，D 的 populated 值为 0，如果 C 中对进程退出，则 B 和 C 中的 populated 值将变为 0，并且会生成cgroup.events文件被修改的事件。

frozen：如果当前 cgroup 处于 frozen 状态，值为 1，否则为 0。

• cgroup.freeze：可读可写，可以通过向该文件写入 1 将 cgroup 设置为 freeze 状态。默认值为 0。

? cat cgroup.freeze
0
? echo 1 > cgroup.freeze
? cat cgroup.freeze
1
? cat cgroup.events
populated 0
frozen 1

• cgroup.max.depth：当前 cgroup 允许创建子 cgroup 最大深度，如果实际深度大于或等于该值，尝试创建新的子 cgroup 会失败。默认值 max 不限制。
• cgroup.max.descendants：当前 cgroup 允许创建子 cgroup 的最大数量，如果实际子 cgroup 数量大于该值，尝试创建新的 cgroup 会失败。默认值 max 不限制。

cgroup.max.depth 和 cgroup.max.descendants 的区别：

cgroup.max.descendants 限制当前 cgroup 下所有子 cgroup 的总和（包括所有子 cgroup）。

? cat cgroup.max.descendants
2
? mkdir test1
? mkdir test2
? mkdir test3
mkdir: cannot create directory ‘test3’: Resource temporarily unavailable

cgroup.max.depth 限制 cgroup 树的深度：

? cat cgroup.max.depth
2
? mkdir test1
? mkdir test1/test2
? mkdir test1/test2/test3
mkdir: cannot create directory ‘test1/test2/test3’: Resource temporarily unavailable

• cgroup.procs：可读可写，处于当前 cgroup 中的所有进程，每行一个 PID，没有顺序，并且可能存在重复（进程被移走后再次加入当前 cgroup）。向该文件中写入 PID 可以将进程加入 cgroup。

? cat cgroup.procs
? echo 34256 > cgroup.procs
? cat cgroup.procs
34256

• cgroup.threads：可读可写，处于当前 cgroup 中的所有线程，每行一个 TID，没有顺序，并且可能存在重复。

向cgroup.procs中写入 PID 后，cgroup 会向cgroup.threads文件中追加进程中所有线程的 TID。

? cat cgroup.threads
34256
34257
34258
34259
34260
34261

• cgroup.stat：只读文件，展示当前 cgroup 的状态，包括以下字段：

? cat cgroup.stat
nr_descendants 2
nr_dying_descendants 0

nr_descendants：当前 cgroup 下子 cgroup 的总数。

mkdir test2
? cat cgroup.stat
nr_descendants 3
nr_dying_descendants 0

nr_dying_descendants：当前 cgroup 下正在被删除的子 cgroup 数量。

• cgroup.subtree_control：可读可写，当前 cgroup 的子 cgroup 启用的 controller 列表。向该文件写入以“+”或“-”为前缀的 controller 名称列表为子 cgroup 启用或禁用 controller。

? cat cgroup.subtree_control
? echo "+memory" > cgroup.subtree_control
? cat test1/cgroup.controllers
memory

当前 cgroup 中存在进程时，写入不会成功：

? echo "+memory" > cgroup.subtree_control
echo: write error: device or resource busy

写入当前 cgroup 没有启用的 controller 时，不会成功：

? cat cgroup.controllers
memory
? echo "+cpu" > cgroup.subtree_control
echo: write error: no such file or directory

当同时写入多个 controller 时，要么全成功，要么全失败，不存在部分成功的情况：

? echo "+memory +cpu" > cgroup.subtree_control
echo: write error: no such file or directory
? cat test1/cgroup.controllers

虽然启用 memory controller 可以成功，但是启用 cpu controller 的时候失败了，所以 memory controller 也没有启用。

• cgroup.type：可读可写，存在于非 root cgroup 中。可选的值：

“domain”：正常的有效 domain cgroup，默认类型。

“domain threaded”：threaded 类型 domain cgroup，作为 threaded 子树的根结点。

“domain invalid”：无效的 cgroup，不能启用 controller，不能加入进程。可以转换为 threaded 类型的 cgroup。

“threaded”：threaded 类型 cgroup，位于 threaded 子树中。

? cat cgroup.type
domain

• cpu.pressure

当前 cgroup 的 CPU 压力情况，基于 PSI（Pressure Stall Information）实现，这是 kernel 引入的一种评估系统压力的机制。内容如下：

? cat cpu.pressure
some avg10=0.00 avg60=0.00 avg300=0.00 total=0
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

pressure值分为两行，avg10、avg60、avg300 分别表示 10s、60s、300s 时间周期内阻塞（stall）时间的百分比。total 是累计时间，单位 ms。

some行表示只有有一个任务在 cpu 资源上阻塞。full?行表示所有非 idle 状态任务同时在 cpu 资源上阻塞，此时，cpu 资源完全浪费，严重影响性能。

在以下示例中，每个格子代表 10s，有颜色的格子代表在这段时间（为了方便，以 10s 为单位）内 cpu 处于阻塞状态。

some 阻塞时间的百分比为 80s/100s=80%，full 阻塞时间的百分比为 30/100=30%。

• io.pressure

和cpu.pressure类似，表示当前 cgroup 内 io 资源阻塞时间的占比。

? cat io.pressure
some avg10=0.00 avg60=0.00 avg300=0.00 total=0
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

• memory.pressure

和cpu.pressure类似，表示当前 cgroup 内 memory 资源阻塞时间的占比。

? cat cpu.pressure
some avg10=0.00 avg60=0.00 avg300=0.00 total=0
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

• cpu.stat：统计当前 cgroup 中 cpu 资源的使用情况。

? cat cpu.stat
usage_usec 2400
user_usec 0
system_usec 2400

usage_usec：总的 cpu 时间。

user_usec：用户态进程占用 cpu 的时间。

system_usec：内核态进程占用 cpu 的时间。

V1 和 V2 主要区别

参考 facebook Chris Down 提到的例子。

在 cgroup v1 中，每种资源一个层级。对于 bg 和 adhoc 两个 cgroup，bg 需要限制 blkio 和 memory 两种资源，adhoc 需要限制 memory 和 pids 两种资源。cgroup v1 场景的视图如下：

对于 cgroup v2，由于所有资源都在同一个 cgroup 下管理，通过 cgroup.sub_controller 控制子 cgroup 启用的 controller，这样一来，视图以 cgroup 为单位，更加清晰和便于管理。

参考资料

[1] process containers:?https://lwn.net/Articles/236038/

[2] unified hierarchy:?https://lkml.org/lkml/2014/3/13/503

[3] cgroup v2:?https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/Documentation/cgroup-v2.txt?id=v4.5&id2=v4.4

[4] 只对 cpuset 子系统有效:?https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt

[5] 在 cgroup V2 中已经移除:?https://www.kernel.org/doc/Documentation/cgroup-v2.txt

[6] PSI:?https://docs.kernel.org/accounting/psi.html#psi

[7] Chris Down 提到的例子:?https://chrisdown.name/talks/cg

【容器原理之cgroup - 知乎】更多关于docker核心原理可自行查看