2 限制容器
Linux Namespace创建了一个“容器”，为什么还要对容器做“限制”？
以PID Namespace为例：
虽然容器内的第1号进程在“障眼法”干扰下只能看到容器里的情况，但在宿主机，它作为第100号进程与其他所有进程之间依然是平等竞争关系。
这意味着，虽然第100号进程表面上被隔离，但它所能够使用到的资源（比如CPU、内存），可随时被宿主机其他进程（或容器）占用。当然，该100号进程也可能自己就把所有资源吃光。这些显然都不是一个“沙盒”的合理行为。
于是，就有了下面的
3 Cgroups（ control groups）
2006由Google工程师发起，曾将其命名为“进程容器”（process container）。实际上，在Google内部，“容器”这个术语长期以来都被用于形容被Cgroups限制过的进程组。后来Google的工程师们说，他们的KVM虚拟机也运行在Borg所管理的“容器”里，其实也是运行在Cgroups“容器”当中。这和我们今天说的Docker容器差别很大。
2008年并入 Linux Kernel 2.6.24。它最主要的作用，就是限制一个进程组能够使用的资源上限，包括CPU、内存、磁盘、网络带宽等等。
Docker实现CPU、内存、网络的限制也均通过cgroups实现。
此外，Cgroups还能够对进程进行优先级设置、审计，以及将进程挂起和恢复等操作。只探讨它与容器关系最紧密的“限制”能力，并通过一组实践来认识一下Cgroups。
在Linux中，Cgroups给用户暴露出来的操作接口是文件系统，即它以文件和目录的方式组织在os的/sys/fs/cgroup路径。
在笔者的 CentOS7 VM里，可以用mount指令把它们展示出来
它的输出结果，是一系列文件系统目录(如果你在自己的机器上没有看到这些目录，那你就需要自己去挂载Cgroups)
在/sys/fs/cgroup下面有很多诸如cpuset、cpu、 memory这样的子目录，也叫子系统
这些都是我这台机器当前可以被Cgroups进行限制的资源种类。
而在子系统对应的资源种类下，你就可以看到该类资源具体可以被限制的方法。
譬如,对CPU子系统来说，就可以看到如下配置文件
注意到cfs_period和cfs_quota这样的关键词,这两个参数需要组合使用，可用来
限制进程在长度为cfs_period的一段时间内，只能被分配到总量为cfs_quota的CPU时间
这样的配置文件如何使用呢？
需要在对应的子系统下面创建一个目录
比如，我们现在进入/sys/fs/cgroup/cpu目录下：
这个目录就称为一个“控制组”。
OS会在你新创建的container目录下，自动生成该子系统对应的资源限制文件!
4 Cgroups实战
4.1 创建 CPU 100%的进程
- 执行脚本
死循环可致CPU 100%，top确认：
此时，可以查看container目录下的文件，看到
- container控制组里的CPU quota还没有任何限制（即：-1）
CPU period则是默认的100 ms（100000 us）：
4.2 限制该进程
接下来修改这些文件的内容来设置限制。
- 向container组里的cfs_quota文件写入20 ms（20000 us）
- 即100ms，被该控制组限制的进程只能使用20ms的CPU，即该进程只能使用到20%的CPU带宽。
- 接下来把被限制的进程的PID写入container组里的tasks文件，上面的设置就会对该进程生效
- top，可见CPU使用率立刻降到20%
除CPU子系统外，Cgroups的每一项子系统都有其独有的资源限制能力，比如：
- blkio，为块设备设定I/O限制，一般用于磁盘等设备
- cpuset，为进程分配单独的CPU核和对应的内存节点
- memory，为进程设定内存使用的限制
5 Docker中如何限制？
Cgroups 就是一个子系统目录加上一组资源限制文件的组合
而对于Docker等Linux容器，只需在每个子系统下面，为每个容器创建一个控制组（即创建一个新目录），然后在启动容器进程之后，把这个进程的PID填写到对应控制组的tasks文件中!
而至于在这些控制组下面的资源文件里填上什么值，就靠用户执行docker run时的参数指定
- Docker ≥1.13
docker run -it --cpus=".5" ubuntu /bin/bash
- Docker ≤1.12
docker run -it --cpu-period=100000 --cpu-quota=50000 ubuntu /bin/bash
启动容器后，可通过查看Cgroups文件系统下，CPU子系统中，“docker”这个控制组里的资源限制文件的内容来确认：
cat /sys/fs/cgroup/cpu/docker/5d5c9f67d/cpu.cfs_period_us xxx cat /sys/fs/cgroup/cpu/docker/5d5c9f67d/cpu.cfs_quota_us xxx
6 总结
容器只是一种特殊的进程，一个正在运行的Docker容器，就是一个启用了多个Linux Namespace的应用进程，而该进程能够使用的资源量，则受Cgroups限制。即容器是一个“单进程”模型。
由于一个容器本质就是一个进程，用户的应用进程实际上就是容器里PID=1的进程，也是其他后续创建的所有进程的父进程。
这意味着，在一个容器，无法同时运行两个不同应用，除非你能事先找到一个公共的PID=1的程序充当两个不同应用的父进程，这也解释了为何很多人会用systemd或supervisord这样的软件代替应用本身作为容器的启动进程。
容器本身设计就是希望容器和应用能同生命周期，这对容器的编排很重要。否则，一旦出现类似于“容器是正常运行的，但是里面的应用早已经挂了”的情况，编排系统处理起来就非常麻烦了。
跟Namespace的情况类似，Cgroups对资源的限制能力也有很多不完善的地方，被提及最多的就是/proc文件系统的问题。
如果在容器里执行top，会发现它显示的信息是宿主机的CPU和内存数据，而不是当前容器的。造成这个问题的原因就是，/proc文件系统并不知道用户通过Cgroups给这个容器做了什么样的资源限制，即：/proc文件系统不了解Cgroups限制的存在。
在生产环境中，这个问题必须修正，否则应用程序在容器里读取到的CPU核数、可用内存等信息都是宿主机上的数据，这会给应用的运行带来非常大的困惑和风险。这也是在企业中，容器化应用碰到的一个常见问题，也是容器相较于虚拟机另一个不尽如人意的地方
参考
- Docker官网
- Docker实战
- 深入剖析Kubernetes
- https://tech.meituan.com/2015/03/31/cgroups.html
