Linux Control Cgroups

无论 Docker 如何进行隔离，无法否认的是我们在当前宿主机中运行的所有容器，它依赖的硬件资源都只是当前机器。

其实启动的每一个容器进程，它本身其实就是当前宿主机的进程之一，那么本质上来说，它也会和宿主机中的其他进程进行资源的竞争。

一、Control Cgroups

所以我们就要针对Docker运行的容器进行资源的限制，Cgroups 就是 Linux 内核中用来为进程设置资源的一个技术。

Linux Cgroups 的全称是 Linux Control Group。它最主要的作用，就是限制一个进程组能够使用的资源上限，包括 CPU、内存、磁盘、网络带宽等等。

还可以对进程进行优先级设置，审计，挂起和恢复等操作。

Linxu中为了方便用户使用cgroups，已经把其实现成了文件系统，其目录在/sys/fs/cgroup下，在 /sys/fs/cgroup 下面有很多诸如 cpuset、cpu、 memory 这样的子目录，也叫子系统。这些都是我这台机器当前可以被 Cgroups 进行限制的资源种类。Cgroups 的每一个子系统都有其独有的资源限制能力，比如：

cpu：限制进程在一段时间内能够分配到的 CPU 时间

blkio：为块设备设定 I/O 限制，一般用于磁盘等设备

cpuset：为进程分配单独的 CPU 核和对应的内存节点

memory：为进程设定内存使用的限制

完整子系统如下图：

补充：当然这里面还牵扯到许多其他的问题，比如是如何实现的，资源如何分配等等。

我们可以把 Linux Cgroups 理解成一个子系统目录加上一组资源限制文件的组合。而对于 Docker 等 Linux 容器项目来说，它们只需要在每个子系统下面，为每个容器创建一个控制组（即创建一个新目录），然后在启动容器进程之后，把这个进程的 PID 填写到对应控制组的 tasks 文件中就可以了。而至于在这些控制组下面的资源文件里填上什么值，就靠用户执行 docker run 时的参数指定了。

二、Cgroups 存在的问题

跟 Namespace 的情况类似，Cgroups 对资源的限制能力也有很多不完善的地方，被提及最多的自然是 /proc 文件系统的问题。

我们知道，Linux 下的 /proc 目录存储的是记录当前内核运行状态的一系列特殊文件，用户可以通过访问这些文件，查看系统以及当前正在运行的进程的信息，比如 CPU 使用情况、内存占用率等，这些文件也是 top 指令查看系统信息的主要数据来源。

但是，你如果在容器里执行 top 指令，就会发现，它显示的信息居然是宿主机的 CPU 和内存数据，而不是当前容器的数据。

我在容器中执行 free 命令，展示的是我宿主机的相关信息。

造成这个问题的原因就是，/proc 文件系统并不知道用户通过 Cgroups 给这个容器做了什么样的资源限制，即： /proc 文件系统不了解 Cgroups 限制的存在。