本文主要转载自Linux的cgroup功能（二）：资源限制cgroup v1和cgroup v2的详细介绍
1.简介
1.1 术语
process是“进程”，task是“线程”。
subsystem或者resource controllers是cgroup中某一类资源的管理器，例如管理cpu的叫做cpu controller，管理内存的叫做memory controller，统一称呼为“cgroup控制器”。
controller要使用mount -t cgroup样式的命令挂载到一个目录中，这个操作称呼为“挂载cgroup controller”。
从linux kernel 4.14开始，cgroup v2 引入了thread mode（线程模式），controller被分为domain controller和threaded controller，前者称为“cgroup进程控制器”，后者称为“cgroup线程控制器”。
从使用的角度看，cgroup就是一个目录树，目录中可以创建子目录，这些目录称为“cgroup 目录”，在一些场景中为了体现层级关系，还会称为“cgroup 子目录”。
每个目录中有一些用来设置对应controller的文件，这些文件称呼为“cgroup控制器的文件接口”。
cgroup v2引入了thread mode（线程模式）之后，cgroup目录有了类型之分：只管理进程的cgroup目录是domain cgroup，称为“进程(子)目录”；新增的管理线程的cgroup目录是threaded cgroup，称为“线程子目录”。
一句话介绍cgroup：把一个cgroup目录中的资源划分给它的子目录，子目录可以把资源继续划分给它的子目录，为子目录分配的资源之和不能超过父目录，进程或者线程可以使用的资源受到它们委身的目录中的资源的限制。
1.2 版本
cgroup有v1和v2两个版本，这是一个非常重要的信息。
v1版本是最早的实现，当时resource controllers的开发各自为政，导致controller间存在不一致，并且controller的嵌套挂载使cgroup的管理非常复杂。
Linux kernel 3.10 开始提供v2版本cgroup（Linux Control Group v2）。开始是试验特性，隐藏在挂载参数-o __DEVEL__sane_behavior中，直到Linuxe Kernel 4.5.0的时候，cgroup v2才成为正式特性。
cgroup v2希望完全取代cgroup v1，但是为了兼容，cgroup v1没有被移除。
cgroup v2实现的controller是cgroup v1的子集，可以同时使用cgroup v1和cgroup v2，但一个controller不能既在cgroup v1中使用，又在cgroup v2中使用。
2. cgroup v1的使用
cgroup v1中，controller可以独立挂载到一个cgroup目录中，也可以和其它controller联合挂载到同一个cgroup目录，cgroup v2也是采用挂载的方式，但是有一些不同（见后文）。
在cgroup v1中，task也就是线程可以被划分到不同的cgroup组中，在一些场景中，这样做是有问题的。
例如在memory controller中，所有task使用的都是同样的内存地址空间，为它们设置不同memory cgroup是没有意义的。（cgroup v2最初将task功能去掉了，后来引入了thread mode来限制线程占用的资源）
2.1 cgroups v1：controller 挂载
controller以tmpfs文件系统的样式挂载到任意目录，通常将其挂载到/sys/fs/cgroup目录。下面是我本地开发机（ubuntu 18.04）的cgroup挂载信息
user@user-600-G5:~$ mount | grep group
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
linux系统通常已经将多个controller挂载在/sys/fs/cgroup目录中了，下面的例子用另一个目录演示。
将多个controller挂载到同一个目录，如下：
mkdir -p /tmp/cgroup/cpu,cpuacct
sudo mount -t cgroup -o cpu,cpuacct none /tmp/cgroup/cpu,cpuacct其中，-t cgroup指定挂载类型，- o指定挂载的controller(可以多个，使用,间隔)
当挂载成功后，再想单独挂载cpu,报错如下,提示已经挂载或者busy，博主解释说可能是controller不允许重复挂载。应该说不通，因为如上面所示，在/sys/fs/cgroup/cpu,cpuacct已经挂载，是cpu不支持单独挂载？还需要再研究下......
user@user-600-G5:~$ mount -t cgroup -o cpu none /tmp/cgroup/cpu
user@user-600-G5:~$ sudo mount -t cgroup -o cpu none /tmp/cgroup/cpu
mount: /tmp/cgroup/cpu: none already mounted on /tmp/cgroup/cpu,cpuacct.
user@user-600-G5:~$ sudo mount -t cgroup -o cpu cgroup_txl /tmp/cgroup/cpu
mount: /tmp/cgroup/cpu: cgroup_txl already mounted or mount point busy.
挂载后，可以看到controller的文件接口：
user@user-600-G5:~$ ls -al /tmp/cgroup/cpu,cpuacct/
总用量 4
dr-xr-xr-x 4 root root 0 10月 15 16:11 .
drwxrwxr-x 3 user user 4096 11月 24 14:33 ..
-rw-r--r-- 1 root root 0 11月 24 14:33 cgroup.clone_children
-rw-r--r-- 1 root root 0 11月 24 14:33 cgroup.procs
-r--r--r-- 1 root root 0 11月 24 14:33 cgroup.sane_behavior
-r--r--r-- 1 root root 0 11月 24 14:33 cpuacct.stat
-rw-r--r-- 1 root root 0 11月 24 14:33 cpuacct.usage
-r--r--r-- 1 root root 0 11月 24 14:33 cpuacct.usage_all
-r--r--r-- 1 root root 0 11月 24 14:33 cpuacct.usage_percpu
-r--r--r-- 1 root root 0 11月 24 14:33 cpuacct.usage_percpu_sys
-r--r--r-- 1 root root 0 11月 24 14:33 cpuacct.usage_percpu_user
-r--r--r-- 1 root root 0 11月 24 14:33 cpuacct.usage_sys
-r--r--r-- 1 root root 0 11月 24 14:33 cpuacct.usage_user
-rw-r--r-- 1 root root 0 11月 24 14:33 cpu.cfs_period_us
-rw-r--r-- 1 root root 0 11月 24 14:33 cpu.cfs_quota_us
-rw-r--r-- 1 root root 0 11月 24 14:33 cpu.shares
-r--r--r-- 1 root root 0 11月 24 14:33 cpu.stat
-rw-r--r-- 1 root root 0 11月 24 14:33 notify_on_release
-rw-r--r-- 1 root root 0 11月 24 14:33 release_agent
drwxr-xr-x 106 root root 0 11月 24 00:06 system.slice
-rw-r--r-- 1 root root 0 11月 24 14:33 tasks
drwxr-xr-x 2 root root 0 11月 24 13:56 user.slice
可以一次挂载所有的controller：
mount -t cgroup -o all cgroup /tmp/cgroup
还可以不挂载任何controller：mount -t cgroup -o none,name=somename none /some/mount/point
没有挂载controller的cgroup可以用来跟踪进程，例如在进程消失导致cgroup为空时，cgroup的通知回调会被触发。
2.2 cgroups v1：controller 卸载
直接用umount卸载：
umount /sys/fs/cgroup/pids
卸载的时候要注意，需要先将所有子目录卸载，否则，umount只会让挂载点不可见，而不是真正将其卸载。
例如， remount刚刚挂载的/tmp/cgroup/cpu,cpuacct/
user@user-600-G5:~$ sudo umount /tmp/cgroup/cpu,cpuacct
user@user-600-G5:~$ ls -al /tmp/cgroup/cpu,cpuacct/
总用量 8
drwxrwxr-x 2 user user 4096 11月 24 14:33 .
drwxrwxr-x 4 user user 4096 11月 24 14:36 ..2.3 cgroups v1：cgroup的创建和进程绑定
cgroup是以目录的形式呈现的，/是cgroup的根目录，注意cgroup的根目录和挂载目录不是一回事，cgroup可能挂载在/sys/fs/cgroup或者/tmp/cgroup等任意目录，无论挂载在哪里，cgroup的根目录都是/。
假设cgroup的cpu controller的挂载点是/sys/fs/cgroup/cpu，那么目录/sys/fs/cgroup/cpu/cg1对应的cgroup的目录是/cg1。
为什么要强调这个，因为在调查一个kubelet的问题的时候，不确定--runtime-cgroups参数值中要不要包含挂载点路径，直到用cadvisor查出所有cgroup后，才确定不应该带有挂载路径。现在从Linux手册中找到支持了：
A cgroup filesystem initially contains a single root cgroup, '/',
which all processes belong to. A new cgroup is created by creating a
directory in the cgroup filesystem:
mkdir /sys/fs/cgroup/cpu/cg1将进程的进程号直接写入到对应cgroup.procs文件中，就完成了进程与cgroup的绑定，例如：
echo $$ > /sys/fs/cgroup/cpu/cg1/cgroup.procs
将进程绑定到cgroup之后，该进程创建的线程也一同被绑定到同一个cgroup。
每个进程只能绑定每个controller的一个cgroup目录，把进程的ID加到controller中的另一个cgroup目录的cgroup.procs文件中时，会自动将其从原先的cgroup.procs文件中移除。
每次只能向cgroup.procs中添加一个进程号，不能批量添加。
从cgroup.procs中读取的进程号的顺序是随意的，并且是可以重复的。
cgroup v1支持将线程（task）绑定到cgroup目录，只需将线程的线程ID写入目标cgroup目录的tasks文件中。
注意，tasks文件中是线程ID，cgroup.procs文件中是进程ID。
2.4 cgroups v1：cgroup的删除
在cgroup子目录已经全部删除，并且没有绑定任何进程、线程的情况下，直接删除cgroup目录即可。
2.5 cgroups v1：cgroup为空时，进行回调通知
每个cgroup中目录中都有下面两个文件：
release_agent notify_on_releasenotify_on_release的内容是0或者1，指示kernel是否要在cgroup为空时（没有cgroup子目录、没有绑定任何进程）发出通知，0为不通知，1为通知。
release_agent是自行设置的、kernel通知时调用的命令， 它的命令行参数有且只有一个，就是当前为空的cgroup目录。
例如：
user@user-600-G5:~$ cat /tmp/cgroup/cpu,cpuacct/release_agent
user@user-600-G5:~$ cat /tmp/cgroup/cpu,cpuacct/notify_on_release
0release_agent也可以在挂载cgroup的时候设置：
mount -o release_agent=pathname ...
3. cgroup v2的使用
cgroups v2支持的所有controller使用统一约定的、固定格式的cgroup目录，并且进程只能绑定到cgroup的/目录和目录树中的叶子节点，不能绑定到中间目录。变化还是比较大的，需要特别注意：
cgorup v2支持的controller默认自动挂载，并且挂载点中的目录结构是固定的- 进程只能绑定到cgroup的“/”目录和cgroup目录树中的叶子节点
- 在
cgroup.controllers和cgroup.subtree_control中设置cgroup目录中可用的controller - cgroup v1中的tasks文件被移除，cpuset controller中的
cgroup.clone_children文件也被移除 - cgroup目录为空时的通知机制得到改进，通过
cgroup.events文件通知
3.1 cgroups v2：controller 挂载
类型为cgroup2：
mount -t cgroup2 none /mnt/cgroup2
一个controller如果已经在cgroup v1中挂载了，那么在cgroup v2中就不可用。如果要在cgroup v2中使用，需要先将其从cgroup v1中卸载。
systemd用到了cgroup v1，会在系统启动时自动挂载controller，因此要在cgroup v2中使用的controller，最好通过内核启动参数cgroup_no_v1=list禁止cgroup v1使用：
cgroup_no_v1=list # list是用逗号间隔的多个controller
cgroup_no_v1=all # all 将所有的controller设置为对cgroup v1不可用3.2 cgroups v2：支持的controller
从Linux kernel 4.14开始，cgroup v2支持线程模式（thread mode），引入该特性后，controller开始分为两类：domain controller（以进程为管理目标的控制器）和 threaded controller（以线程为管理目标的控制器）。
3.2.1 domain controller
io
since 4.5，cgroup v1 的 blkio 的继任者memory
since 4.5，cgroup v1 的 memory 的继任者pids
since 4.5，与 cgroup v1 中的 pids 是同一个perf_event
since 4.5，与 cgroup v1 中的 perf_event 是同一个rdma
since 4.11，与 cgroup v1 中的 rdma 是同一个cpu
since 4.15，cgroup v1 的 cpu、cpuacct 的继任者3.2.2 threaded controller
cpu
perf_event
pids3.3 cgroups v2：cgroup目录
3.3.1 controller的启用/禁止文件
cgroup v2的cgroup目录中有一个cgroup.controllers文件和cgroup.subtree_control文件。
cgroup.controllers文件是只读的，内容是当前目录可用的controller。
cgroup.subtree_control是当前目录中可用的controller的子集，规定了直接子目录可用的controller，即定义了直接子目录中的cgroup.controllers文件的内容。
cgroup.subtree_control的内容格式如下，列出的controller用空格间隔，前面用“+”表示启用，用“-”表示不启用：
echo '+pids -memory' > x/y/cgroup.subtree_control
如果向cgroup.subtree_control中写入cgroup.controllers中不存在的controller，会得到ENOENT错误。
3.3.2 将进程绑定到叶子目录
在cgroup v2中，所有进程都只能绑定到cgroup的叶子目录中。假设cgroup的目录如下，这时候只能在CG1.1、CG1.2和CG2.1中绑定进程：
/
__ __
___/ \___
__/ \__
CG1 CG2
__ __ __
___/ \___ \_
__/ \__ \_
CG1.1 CG1.2 CG2.1man 7 cgroups建议在每个目录下都建立一个名为leaf的目录，这个目录没有任何子目录，专门用来绑定进程。
根据这个建议，上面的目录应该调整成：
/
_______
_____/ \_____
___/ \___
CG1 CG2
__|__ ____
___/ | \___ ___/ \___
__/ | \__ __/ \__
CG1.1 leaf CG1.2 CG2.1 leaf
| | |
leaf leaf leaf需要绑定cgroup进程的进程号都写在名为leaf的目录中。
进程只能绑定到目录树的叶子结点只是一个表面规则，本质规则是：
一个cgroup目录如果绑定了进程，那么它的cgroup.subtree_control必须为空，或者反过来必须不绑定进程，cgroup.subtree_control中才可以有内容。
More precisely, the rule is that a (nonroot) cgroup can’t both (1) have member processes, and (2) distribute resources into child cgroups—that is, have a nonempty cgroup.subtree_control file.
3.3.3 回调通知设置文件
cgroup v1 中的release_agent和notify_on_release被移除了，cgroup v2 提供一个更通用的cgroup.events。
cgroup.events文件是只读的，每行一个key-value对，key和value之间用空格间隔。
现在（2019-01-29 17:39:09），cgroup.events文件中只存在一个名为populated的key，这个key对应的value是这个cgroup中包含的进程数。
如果使用cgroup v2，要用监控cgroup.events文件的方式感知cgroup的变化。
When monitoring this file using inotify(7), transitions generate IN_MODIFY events When monitoring the file using poll(2), transitions cause the bits POLLPRI and POLLERR to be returned in the revents field.
3.3.4 cgroup目录中的其它文件
前面已经接触到文件有：
cgroup.controllers
只读，当前目录中可用的controller
cgroup.subtree_control
读写，子目录中可用的controller
cgroup.events
只读，事件文件，每行一对key value，现在只有一个keypopulated：value是cgroup中包含的进程数
除此之外还有：
cgroup.stat
只读，since 4.14，每行一对key value
nr_descendants： 该cgroup中存活的子cgroup的数量
nr_dying_descendants： 该cgroup中已经死亡的cgroup的数量
一个cgroup目录被删除后，先进入dying状态，等待系统回收。
cgroup.max.depth
since 4.14，当前目录的子目录的最大深度，0表示不能创建子目录，默认值"max"表示不限制,超过限制，返回EAGAIN
cgroup.max.descendants
since 4.14，当前目录中可以创建的活跃cgroup目录的最大数量，默认值"max"表示不限制,超过限制，返回EAGAIN
cgroup.type
since 4.14，位于"/"以外的cgroup目录，标记当前cgroup目录的类型，支持修改，支持以下类型：
domain: 进程子目录，控制进程资源的cgroup
threaded: 线程子目录，控制同一个进程下的线程资源
domain threaded: 线程子目录的根目录，threaded root
domain invalid: 线程子目录中处于无效状态的cgroup目录domain invalid是一个中间状态，对类型为domain invalid的cgroup目录，只能做一个操作：将其类型修改threaded。 它存在的目的是为线程模式的扩展预留空间。
3.4 cgroup v2: 授予非特权用户管理权限
3.4.1 授权方法：修改文件或目录的所有者
特权用户（root用户）可以授予非特权用户（普通用户）管理某个cgroup的权利。
授予方法很简单，直接将一些文件或目录的所有者改成被授权人就可以了，修改的文件或目录不同，被授权人拥有的权限不同。
按照文档中例子，将cgroup目录/dlgt_grp的管理权授予普通用户时，可以有以下几种授权方式：
/dlgt_grp目录的所有者改为被授权人，被授权人拥有该目录下所有新建cgroup目录的管理权。
/dlgt_grp/cgroup.procs文件的所有者改为被授权人，被授权人拥有将进程绑定到该cgroup的权利。
/dlgt_grp/cgroup.subtree_control文件的所有者改为被授权人，被授权人可以决定在子目录中启用哪些出现在/dlgt_grp/cgroup.controllers中controller。
/dlgt_grp/cgroup.threads文件的所有者改为被授权人，线程模式下用到，授予将线程绑定到线程子目录的权利。需要注意的是/dlgt_grp目录中controller的接口文件的所有者不应当被修改，这是上层cgroup目录授予当前目录的。
3.4.2 授权边界：用挂载参数nsdelegate开启
在挂载cgroup v2的时候，使用参数nsdelegate开启授权边界，如果cgroup v2已经挂载，可以remount开启，如下：
mount -t cgroup2 -o remount,nsdelegate none /sys/fs/cgroup/unified
使用该选项之后，cgroup namespace成为授权边界，会对cgroup中的进程进行下面的限制：
1. cgroup中的进程不能对所属cgroup目录中的controller接口文件进行写操作，否则报错`EPERM`
2. cgroup中的进程不能设置namespace边界外的cgroup中的绑定进程，否则报错`ENOENT`cgroup namespace是个什么鬼？？ 2019-01-30 14:28:27
引入cgroup namespace作为授权边界是为了应对下面的情况：
1. 用户用cecilia得到了一个cgroup目录的管理权限，这个目录这里称为当前目录
2. 普通用户cecilia，在当前目录下创建了一个cgroup子目录，并将这个子目录授权给另一个人这种情况下，cecilia同时拥有当前目录和子目录的操作权限，子目录中的进程也是cecilia用户的进程，会出现下面两种非法的操作：
1. 绑定到cecilia的cgroup子目录中的进程能够更改所属cgroup子目录中的controller接口文件
2. 绑定到cecilia的cgroup子目录中的进程能够将进程移出所在cgroup子目录，绑定到cecilia的当前cgroup目录文档中举的例子是，cecilia创建一个容器，容器内的进程绑定到cecilia创建的cgroup子目录。意思似乎是在说：
如果不以namespace为授权边界，那么容器内的进程就能够自己修改controller接口，并且具备脱离所属的cgroup目录、将自己绑定到上层cgroup目录的能力。
这样一来cecilia对容器内进程所做的cgroup限制就形同虚设。这样理解正好和授权边界引入的两个限制对应（或许正确 2019-01-30 14:36:38）。
nsdelegate只在最初挂载的mount namespace中有效，在其它mount namespace中默认忽略：
The nsdelegate mount option only has an effect when performed in the
initial mount namespace; in other mount namespaces, the option is
silently ignored.一个非特权进程只有下面的情况都满足时，才能向cgroup.procs中添加进程：
1. 拥有cgroup.procs文件的写权限
2. 拥有进程原先所属cgroup目录和将要加入的cgroup目录的共同上级目录中cgroup.procs文件的写权限
3. 如果启用了授权边界（nsdelegate），执行操作的进程必须能够看到被操作的进程原先所属cgroup目录和将要加入的cgroup目录
4. Linux kernel 4.11之前，执行操作的进程的UID和被操作进程的User ID或者Set-User-ID匹配以上四条约束带来的直接结果是：被授权给非特权用户的cgroup绑定的第一个进程，只能是授权者设置的，不能由被授权者添加。因为被授权者不能对cgroup子目录中的第一个进程原先所在的cgroup中的cgroup.procs文件进行写操作。
3.5 cgroups v2：线程模式（THREAD MODE）
Linux kernerl 4.14开始，cgroup v2支持线程模式。
线程模式是指：
1. 可以创建线程子目录（threaded subtrees），容纳绑定到该线程子目录的进程创建的所有线程，每个线程可以绑定线程子目录的cgroup子目录。
2. 通过线程控制器（threaded controllers）为线程子目录中的cgroup目录分配资源。
3. 在线程子目录中，非叶子目录可以绑定线程，注意，“只能绑定到叶子目录”的限制在这里放松了。3.5.1 cgroups v2：线程controller
cpu
perf_event
pids在线程子目录中不能使用domain controllers。
3.5.2 cgroups v2：线程模式的使用
3.5.2.1创建线程子目录的方法
- 方法1
1. 直接修改cgroup目录中的cgroup.type，写入threaded
2. 上层cgroup目录（/目录除外）的类型自动变为domain threaded
3. 当前目录的子目录和新建子目录的类型自动变成domain invalid，需要自行将其修改为threaded- 方法2
1. 在当前cgroup目录中启用一个或多个threaded controller，在当前目录中绑定一个进程
2. 当前目录的类型自动变成domain threaded
3. 当前目录的所有非threaded类型的子目录类型自动变成domain invalid，需要自行将其修改为threaded注意如果上层目录的类型是domain invalid，当前目录的类型不能被修改。此外，将当前目录的类型修改为threaded时，需要满足两个条件：
1. 当前目录的子目录都是空的，没有绑定任何进程
2. 当前目录中的cgroup.subtree_control文件中没有启用domain controller配置，否则报错ENOTSUP。即domain controllers不能在线程子目录中使用。
3.5.2.2绑定到线程子目录
将进程ID直接写入线程子目录的cgroup.procs文件中，该进程以及它的线程就都一同绑定到了线程子目录中。
然后可以将这个进程创建的多个线程ID，写入到它绑定的线程子目录的以及子目录的子目录中的cgroup.threads文件，实现线程的绑定。
线程只能绑定到创建它的进程所在的线程子目录树。
domain controller是不关心线程的，它看到的都是进程。
实行线程绑定操作时，需要满足以下条件：
- 执行绑定操作的进程有目标目录中的
cgroup.threads文件的写权限 - 执行绑定操作的进程需要有源目录和目标目录的共同祖先目录中的
cgroup.procs文件的写权限 - 源目录和目标目录必须在同一个线程子目录中，即创建线程的进程所在的线程子目录中，即线程不能与进程分离，否则报错EOPNOTSUPP。
进程子目录中的根目录中cgroup.procs是可读写的，进程子目录中非根目录中的cgroup.procs文件是不可读写的。
cgroup.threads在每个cgroup目录中都存在，包括类型为domain的cgroup目录。
4. cgroup的内核接口文件
/proc/cgroups（since 2.6.24）列出了内核支持的cgroup contoller，以及它们的使用情况：
#subsys_name hierarchy num_cgroups enabled
cpuset 4 1 1
cpu 8 1 1
cpuacct 8 1 1
blkio 6 1 1
memory 3 1 1
devices 10 84 1
freezer 7 1 1
net_cls 9 1 1
perf_event 5 1 1
net_prio 9 1 1
hugetlb 0 1 0
pids 2 1 1四列数据的含义分别是：controller名称、挂载位置ID（在cgroup v2中都为0）、使用该controller的cgroup数量、是否启用。
/proc/[pid]/cgroup（since 2.6.24）进程所属的cgroup，内容格式如下：
hierarchy-ID:controller-list:cgroup-path例如一个容器内进程的cgroup:
# cat /proc/1427/cgroup
11:blkio:/kubepods/besteffort/pode4f8b737-1ad1-11e9-a3a2-5254003b4ace/3647f5a8960c6c003fda011ea26dedcb8d45ce3b4c03cbec31b4f2c9cab7d221
10:freezer:/kubepods/besteffort/pode4f8b737-1ad1-11e9-a3a2-5254003b4ace/3647f5a8960c6c003fda011ea26dedcb8d45ce3b4c03cbec31b4f2c9cab7d221
9:net_prio,net_cls:/kubepods/besteffort/pode4f8b737-1ad1-11e9-a3a2-5254003b4ace/3647f5a8960c6c003fda011ea26dedcb8d45ce3b4c03cbec31b4f2c9cab7d221
8:devices:/kubepods/besteffort/pode4f8b737-1ad1-11e9-a3a2-5254003b4ace/3647f5a8960c6c003fda011ea26dedcb8d45ce3b4c03cbec31b4f2c9cab7d221
7:cpuset:/kubepods/besteffort/pode4f8b737-1ad1-11e9-a3a2-5254003b4ace/3647f5a8960c6c003fda011ea26dedcb8d45ce3b4c03cbec31b4f2c9cab7d221
6:memory:/kubepods/besteffort/pode4f8b737-1ad1-11e9-a3a2-5254003b4ace/3647f5a8960c6c003fda011ea26dedcb8d45ce3b4c03cbec31b4f2c9cab7d221
5:perf_event:/kubepods/besteffort/pode4f8b737-1ad1-11e9-a3a2-5254003b4ace/3647f5a8960c6c003fda011ea26dedcb8d45ce3b4c03cbec31b4f2c9cab7d221
4:pids:/kubepods/besteffort/pode4f8b737-1ad1-11e9-a3a2-5254003b4ace/3647f5a8960c6c003fda011ea26dedcb8d45ce3b4c03cbec31b4f2c9cab7d221
3:cpuacct,cpu:/kubepods/besteffort/pode4f8b737-1ad1-11e9-a3a2-5254003b4ace/3647f5a8960c6c003fda011ea26dedcb8d45ce3b4c03cbec31b4f2c9cab7d221
2:hugetlb:/kubepods/besteffort/pode4f8b737-1ad1-11e9-a3a2-5254003b4ace/3647f5a8960c6c003fda011ea26dedcb8d45ce3b4c03cbec31b4f2c9cab7d221
1:name=systemd:/kubepods/besteffort/pode4f8b737-1ad1-11e9-a3a2-5254003b4ace/3647f5a8960c6c003fda011ea26dedcb8d45ce3b4c03cbec31b4f2c9cab7d221第一列hierarchy-ID与/proc/cgroups的第二列对应，在cgroups v2中hierarchy-ID都为0；第二列是controller名称；第三列是cgroup目录路径。
/sys/kernel/cgroup/delegate（since 4.15）：cgroups v2 中可以授权给其它用户的cgroup文件。
/sys/kernel/cgroup/features（since 4.15）：cgroups v2 支持的功能特性。手上没有kernel 4.15的环境，下面是文档中的例子：
$ cat /sys/kernel/cgroup/delegate
cgroup.procs
cgroup.subtree_control
cgroup.threads
$ cat /sys/kernel/cgroup/features
nsdelegate本文整理自下列文献：
1.Linux的cgroup功能（二）：资源限制cgroup v1和cgroup v2的详细介绍
评论 (0)