cgroup--(4)cgroup v1和cgroup v2的详细介绍

adtxl
2021-11-24 / 0 评论 / 6,319 阅读 / 正在检测是否收录...

本文主要转载自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_release
notify_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
0

release_agent也可以在挂载cgroup的时候设置:

mount -o release_agent=pathname ...

3. cgroup v2的使用

cgroups v2支持的所有controller使用统一约定的、固定格式的cgroup目录,并且进程只能绑定到cgroup的/目录和目录树中的叶子节点,不能绑定到中间目录。变化还是比较大的,需要特别注意:

  1. cgorup v2支持的controller默认自动挂载,并且挂载点中的目录结构是固定的
  2. 进程只能绑定到cgroup的“/”目录和cgroup目录树中的叶子节点
  3. cgroup.controllerscgroup.subtree_control中设置cgroup目录中可用的controller
  4. cgroup v1中的tasks文件被移除,cpuset controller中的cgroup.clone_children文件也被移除
  5. 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
pids

3.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.1CG1.2CG2.1中绑定进程:

                   /
                 __ __
             ___/     \___
          __/             \__
         CG1              CG2
        __ __              __
    ___/     \___            \_
 __/             \__           \_
CG1.1            CG1.2         CG2.1

man 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_agentnotify_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,现在只有一个key
populated: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是不关心线程的,它看到的都是进程。

实行线程绑定操作时,需要满足以下条件:

  1. 执行绑定操作的进程有目标目录中的cgroup.threads文件的写权限
  2. 执行绑定操作的进程需要有源目录和目标目录的共同祖先目录中的cgroup.procs文件的写权限
  3. 源目录和目标目录必须在同一个线程子目录中,即创建线程的进程所在的线程子目录中,即线程不能与进程分离,否则报错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 v2hierarchy-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的详细介绍

1

评论 (0)

取消