Docker技术原理之Linux Cgroups（资源限制）

0.前言

首先要知道一个运行的容器，其实就是一个受到隔离和资源限制的Linux进程——对，它就是一个进程。前面我们讨论了Docker容器实现隔离用到的技术Linux namespace，本篇我们来讨论容器实现资源限制的技术 Linux CGroups。

1.关于Linux CGroups

Linux Cgroups的全称是Linux Control Groups。它最主要的作用，就是限制一个进程组能够使用的资源上限，包括CPU、内存、磁盘、网络带宽等等。此外，还能够对进程进行优先级设置，以及将进程挂起和恢复等操作。

在Linux中，Cgroups给用户暴露出来的操作接口是文件系统，即它以文件和目录的方式组织在操作系统的/sys/fs/cgroup路径下。在我的centos服务器下，用mount指令把它们展示出来：

//CentOS Linux release 7.5.1804
$ mount -t cgroup
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_prio,net_cls)
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)

可以看到，在/sys/fs/cgroup下面有很多诸如cpuset、cpu、 memory这样的子目录，也叫子系统。这些都是我这台机器当前可以被Cgroups进行限制的资源种类。而在子系统对应的资源种类下，你就可以看到该类资源具体可以被限制的方法。比如，对CPU子系统来说，我们就可以看到如下几个配置文件：

$ ls /sys/fs/cgroup/cpu
cgroup.clone_children  cgroup.sane_behavior  cpu.rt_period_us   cpu.stat       cpuacct.usage_percpu  system.slice
cgroup.event_control   cpu.cfs_period_us     cpu.rt_runtime_us  cpuacct.stat   notify_on_release     tasks
cgroup.procs           cpu.cfs_quota_us      cpu.shares         cpuacct.usage  release_agent         user.slice

2.举个例子(CPU限制)

1) 配置你的控制组

$ cd /sys/fs/cgroup/cpu
$ mkdir testlimit
$ ls testlimit/
cgroup.clone_children  cgroup.procs       cpu.cfs_quota_us  cpu.rt_runtime_us  cpu.stat      cpuacct.usage         notify_on_release
cgroup.event_control   cpu.cfs_period_us  cpu.rt_period_us  cpu.shares         cpuacct.stat  cpuacct.usage_percpu  tasks

$ cat /sys/fs/cgroup/cpu/testlimit/cpu.cfs_quota_us
-1
$ cat /sys/fs/cgroup/cpu/testlimit/cpu.cfs_period_us 
100000

你创建的这个目录testlimit就称为一个“控制组”。你会发现，操作系统会在你新创建的目录下，自动生成该子系统对应的资源限制文件。可以看到testlimit控制组里的CPU quota还没有任何限制（即：-1），CPU period则是默认的100000us

配置一个只能使用30%cpu的限制，即长度为cfs_period的一段时间内，只能被分配到总量为cfs_quota的CPU时间。

$ echo 30000 > /sys/fs/cgroup/cpu/testlimit/cpu.cfs_quota_us

至此我们的testlimit控制组就配置好了，它限制进程在100000us里只能使用30000us的cpu时间。只是目前没有将它应用于任何进程。

2) 执行脚本

$ while : ; do : ; done &
[1] 4477

该脚本执行了一个无限循环，可以把cpu吃到100%，可以看到它在后台的进程id是4477，后面限制的时候我们会用到。

通过top查看cpu使用情况：

%Cpu0  :100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st

3) 使用cgroups限制该进程的cpu

执行如下命令，使用刚才配置好的testlimit控制组，限制上面4477号进程的cpu：

$ echo 4477 > /sys/fs/cgroup/cpu/testlimit/tasks 

再次通过top查看cpu使用情况：

%Cpu0  : 30.1 us,  3.0 sy,  0.0 ni, 65.5 id,  1.0 wa,  0.0 hi,  0.3 si,  0.0 st

可以看到使用刚才创建的testlimit控制组，将cpu被限制到了30%左右。

4) 启动一个容器加上CPU时钟周期限制

接下来，我们启动一个容器，并加上cpu限制，然后看看cgroups对应的目录里有没有该容器的限制。

$ docker run -td --cpu-period 100000 --cpu-quota 200000 busybox /bin/sh -c "while : ; do : ; done"
c3e3fb30f3cbdcc707dff9f5937018c0ac6b07002d80656760026111c569ca4f

//查看该容器的进程id: 26430
$ ps -x |grep '/bin/sh'
26430 pts/0    Rs+   20:52 /bin/sh -c while : ; do : ; done

//查看cgroups
$ cat /sys/fs/cgroup/cpu/docker/c3e3fb30f3cbdcc707dff9f5937018c0ac6b07002d80656760026111c569ca4f/cpu.cfs_period_us 
100000
$ cat /sys/fs/cgroup/cpu/docker/c3e3fb30f3cbdcc707dff9f5937018c0ac6b07002d80656760026111c569ca4f/cpu.cfs_quota_us 
200000
$ cat /sys/fs/cgroup/cpu/docker/c3e3fb30f3cbdcc707dff9f5937018c0ac6b07002d80656760026111c569ca4f/tasks 
26430

$ top
%Cpu0  : 50.8 us, 49.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st

如上所示，可以通过启动容器时返回的容器ID在cgroups中找到对应的限制。

3.对照Docker源码

// New creates and initializes a new containerd server
func New(ctx context.Context, config *Config) (*Server, error) {
    //...
    if err := apply(ctx, config); err != nil {
        return nil, err
    }
    //...
}

// apply sets config settings on the server process
func apply(ctx context.Context, config *Config) error {
    if config.OOMScore != 0 {
        log.G(ctx).Debugf("changing OOM score to %d", config.OOMScore)
        if err := sys.SetOOMScore(os.Getpid(), config.OOMScore); err != nil {
            log.G(ctx).WithError(err).Errorf("failed to change OOM score to %d", config.OOMScore)
        }
    }
    if config.Cgroup.Path != "" {
        cg, err := cgroups.Load(cgroups.V1, cgroups.StaticPath(config.Cgroup.Path))
        if err != nil {
            if err != cgroups.ErrCgroupDeleted {
                return err
            }
            if cg, err = cgroups.New(cgroups.V1, cgroups.StaticPath(config.Cgroup.Path), &specs.LinuxResources{}); err != nil {
                return err
            }
        }
        if err := cg.Add(cgroups.Process{
            Pid: os.Getpid(),
        }); err != nil {
            return err
        }
    }
    return nil
}

在上面代码中，创建容器时会调用apply接口，里面的cgroups.Load调用就会去加载cgroups，cg.Add把创建的容器进程加入到cgroups task中。

4.下一代Linux Cgroups

在Kernel 3.16后，引入了一个叫__DEVEL__sane_behavior的特性（还在开发试验阶段），它可以把所有子系统都挂载到根层级下，只有叶子节点可以存在tasks，非叶子节点只进行资源控制。
The unified control group hierarchy in 3.16

参考

• 左耳朵耗子-LINUX CGROUP
• redhat资源管理指南
• Fixing control groups
• The unified control group hierarchy in 3.16