浅谈Cgroups（二）

1. 背景

上一篇文章《浅谈Cgroups》对cgroup v1进行了介绍，但是由于当前k8s使用cephfs进行数据存储，当多租户使用时，需要对IO进行限制。当前cgroup v1由于memcg与blkio没有协作，导致buffer io的throttle一直没有实现。并且cgroup v1在内核的实现一直比较混乱，其中主要的原因在于，cgroup为了提供灵活性，允许进程可以属于多个hierarchy的不同的group。但实际上，多个hierarchy并没有太大的用处，因为控制器(controller)只能属于一个hierarchy。 所以在实际使用中，通常是每个hierarchy一个控制器。

这种多hierarchy除了增加代码的复杂度和理解困难外，并没有太大的用处。一方面，跟踪进程所有controller变得复杂;另外，各个controller之间也很难协同工作(因为controller可能属于不同的hierarchy, 所以从3.16开始，内核开始转向单一层次(unified hierarchy)。并且实现了对buffer io的限制。

2. Cgroups v2的变化

由于Cgroups v1存在的种种问题，Cgroups v2将多hierarchy的方式变成了unified hierarchy，并将所有的controller挂载到一个unified hierarchy。

当前kernel没有移除Cgroups v1版本，允许Cgroups v1和v2两个版本共存。但是相同的controller不能同时mount到这两个不同的Cgroup版本中。

以下是Cgroups v2的五点改进：

• Cgroups v2 中所有的controller都会被挂载到一个unified hierarchy下，不在存在像v1中允许不同的controller挂载到不同的hierarchy的情况
• Proess只能绑定到cgroup的根(“/“)目录和cgroup目录树中的叶子节点
• 通过cgroup.controllers和cgroup.subtree_control指定哪些controller可以被使用
• v1版本中的task文件和cpuset controller中的cgroup.clone_children文件被移除
• 当cgroup为空时的通知机制得到改进，通过cgroup.events文件通知

3. unified hierarchy

在Cgroups v1允许将不同的controller挂载到不同的hierarchies虽然很灵活，但实际上这种方式对于使用者来说是没有必要的。因此在Cgroups v2版本中，将所有的controller都挂载到一个hierarchies。

可以使用下面命令将Cgroups v2挂载到文件系统，并且所有可用的controller会自动被挂载进去。

 
 
 
 

  
  
  
  
mount -t cgroup2 none $MOUNT_POINT
 
 
 
 

一个contoller无法在Cgroups v1和v2中同时使用，如果想在Cgroups v2使用已经被Cgroups v1使用的controller，则需要先将其从Cgroups v1中umount掉。

要注意的是，系统启动时，systemd默认使用Cgroups v1，并将可以使用的controller mount到/sys/fs/cgroup。如果想在系统启动时，把Cgroups v1关掉，可以在/etc/default/grub文件下修改kernel参数,增加GRUB_CMDLINE_LINUX_DEFAULT="cgroup_no_v1=all"。(all表示关闭所有的controller，如果想关闭指定的controller，则将all替换成你需要的controller名称，并已逗号分隔即可)。这样就可以在Cgroups v2中使用你想要的controller了。

4. controllers

当前cgroup v2支持以下controller:

• io (since Linux 4.5)
• memory (since Linux 4.5)
• pids (since Linux 4.5)
• perf_event (since Linux 4.11)
• rdma (since Linux 4.11)
• cpu (since Linux 4.15)

5. subtree control

在hierarchy下的每一个Cgroup中都会包含如下两个文件

• cgroup.controllers：这是一个read-only文件。包含了该Cgroup下所有可用的controllers.
• cgroup.subtree_control：这个文件中包含了该Cgroup下已经被开启的controllers。 并且cgroup.subtree_control中包含的controllers是cgroup.controllers文件controller的子集。

cgroup.subtree_control文件内容格式如下,controller之间使用空格间隔，前面用”+”表示启用,使用”-“表示停用。比如下面的例子：

 
 
 
 

  
  
  
  
echo '+pids -memory' > x/y/cgroup.subtree_control
 
 
 
 

Cgroups v2的具体组织结构如下图所示：

6. "no internal processes" rule

与Cgroups v1不同, Cgroups v2只能将进程绑定到叶子节点。因此不能绑定进程到任何一个已开启controller的任何subgroup中。

7. cgroup.events file

在Cgroups v2的实现中，也对获取group empty时获取通知的机制进行了优化。

Cgroups v1使用release_agent和notify_on_release在v2中被移除。替代的是使用了cgroup.events文件。这是一个只读的文件，每行一个key value对，key和value之间通过空格分割。

当前在这个文件中只含有一个key就是populated，对应的value是0。0表示cgroup中没有process，1表示cgroup中包含process。

8. cgroup.stat file

在Cgroups v2 hierarchy下的每个group都会包含一个只读文件cgroup.stat。它的内容也是key-value的形式。当前这个文件中包含如下两个key：

• nr_descendants：表示cgroup中存活的subgroup的数量
• nr_dying_descendants：表示cgroup中已经死亡的cgroup的数量

9. 后代Cgroups数量限制

在Cgroups v2 hierarchy中还包含了两个用于查看和设置该Cgroups下的后代Cgroups数量的限制文件：

• cgroup.max.depth (since Linux 4.14)：这个文件定义子cgroup的***深度。0意味着不能创建cgroup。如果尝试创建cgroup，会报EAGAIN错误;max表示没有限制，默认值是max。
• cgroup.max.descendants (since Linux 4.14)：当前可以创建的活跃cgroup目录的***数量，默认值”max”表示不限制。超过限制，返回EAGAIN。

【本文是专栏机构360技术的原创文章，微信公众号“360技术（ id: qihoo_tech）”】

名称栏目：浅谈Cgroups（二）
文章来源：http://www.shufengxianlan.com/qtweb/news45/450845.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联