# 隔离与限制 容器的隔离与限制是基于下面两个技术来实现的： * **namespace** * **Cgroups** ## Namespace 在了解容器的namespace之前需要明白一点就是程序和进程之间的关系。 程序是保存在电脑上的静态文件，一旦“程序”被执行起来，它就从磁盘上的二进制文件，变成了计算机内存中的数据、寄存器里的值、堆栈中的指令、被打开的文件，以及各种设备的状态信息的一个集合。像这样一个程序运行起来后的计算机执行环境的总和成为了进程。 对于进程来说，它的静态表现就是程序，平常都安安静静地待在磁盘上；而一旦运行起来，它就变成了计算机里的数据和状态的总和，这就是它的动态表现。 **容器技术的核心功能，就是通过约束和修改进程的动态表现，从而为其创造出一个“边界”。** 对于 Docker 等大多数 Linux 容器来说，**Cgroups** 技术是用来制造约束的主要手段，而 **Namespace** 技术则是用来修改进程视图的主要方法。 让我们首先创建一个容器来试试。假设我们已经有了一个 Linux 操作系统上的 Docker 项目在运行，执行下面这条指令： ``` $ docker run -it busybox /bin/sh / # ``` Ubuntu机器就变成了一个宿主机，而一个运行着 /bin/sh 的容器，就跑在了这个宿主机里面。 如果在容器中执行ps命令： ``` / # ps PID USER TIME COMMAND 1 root 0:00 /bin/sh 10 root 0:00 ps ``` 可以看到，在 Docker 里最开始执行的 /bin/sh，就是这个容器内部的第 1 号进程（PID=1），而这个容器里一共只有两个进程在运行。这就意味着，前面执行的 /bin/sh，以及我们刚刚执行的 ps，已经被 Docker 隔离在了一个跟宿主机完全不同的世界当中。 如果在宿主机上运行一个进程，通过会分配一个进程ID，而ID为1的进程为init进程。而此时容器中的ID为1的进程变成了/bin/sh，这说明此时容器的进程列表与宿主机的进程列表是不同的。其实这是docker通过namespace技术对应用的进程空间施加了障眼法，使得它只能看到自己进程空间下的进程而无法看到宿主机进程空间中的进程。 这种技术，就是 Linux 里面的 Namespace 机制。而 Namespace 其实只是 Linux 创建新进程的一个可选参数。在 Linux 系统中创建线程的系统调用是 clone()，比如： ``` int pid = clone(main_function, stack_size, SIGCHLD, NULL); ``` 新创建的这个进程将会“看到”一个全新的进程空间，在这个进程空间里，它的 PID 是 1。之所以说“看到”，是因为这只是一个“障眼法”，在宿主机真实的进程空间里，这个进程的 PID 还是真实的数值，比如 100。 **除了刚刚用到的 PID Namespace，Linux 操作系统还提供了 Mount、UTS、IPC、Network 和 User 这些 Namespace，用来对各种不同的进程上下文进行“障眼法”操作。** 比如，Mount Namespace，用于让被隔离进程只看到当前 Namespace 里的挂载点信息；Network Namespace，用于让被隔离进程看到当前 Namespace 里的网络设备和配置。 **所以说，容器，其实是一种特殊的进程而已。** **理解了 Namespace 的工作方式之后，就会明白，跟真实存在的虚拟机不同，在使用 Docker 的时候，并没有一个真正的“Docker 容器”运行在宿主机里面。Docker 项目帮助用户启动的，还是原来的应用进程，只不过在创建这些进程时，Docker 为它们加上了各种各样的 Namespace 参数。** **Namespace 技术实际上修改了应用进程看待整个计算机“视图”，即它的“视线”被操作系统做了限制，只能“看到”某些指定的内容。** 从之前的docker overview文章中已经非常清楚的了解了docker相较于虚拟机的一些非常突出的优点。但是基于Linux namespace的隔离机制与虚拟机相比也存在不足：**其中最主要的问题就是：隔离得不彻底。** **首先，既然容器只是运行在宿主机上的一种特殊的进程，那么多个容器之间使用的就还是同一个宿主机的操作系统内核。** 尽管你可以在容器里通过 Mount Namespace 单独挂载其他不同版本的操作系统文件，比如 CentOS 或者 Ubuntu，但这并不能改变共享宿主机内核的事实。这意味着，如果你要在 Windows 宿主机上运行 Linux 容器，或者在低版本的 Linux 宿主机上运行高版本的 Linux 容器，都是行不通的。 而相比之下，拥有硬件虚拟化技术和独立 Guest OS 的虚拟机就要方便得多了。最极端的例子是，Microsoft 的云计算平台 Azure，实际上就是运行在 Windows 服务器集群上的，但这并不妨碍你在它上面创建各种 Linux 虚拟机出来。 **其次，在 Linux 内核中，有很多资源和对象是不能被 Namespace 化的，最典型的例子就是：时间。** 如果容器中的程序使用 settimeofday(2) 系统调用修改了时间，整个宿主机的时间都会被随之修改**。**相比于在虚拟机里面可以随便折腾的自由度，在容器里部署应用的时候，“什么能做，什么不能做”，就是用户必须考虑的一个问题。 此外，由于上述问题，共享宿主机内核的事实，容器给应用暴露出来的攻击面是相当大的，应用“越狱”的难度自然也比虚拟机低得多。 ## Cgroups 虽然容器中的进程表面上被隔离了起来，但是它所能够使用到的资源（比如 CPU、内存），却是可以随时被宿主机上的其他进程（或者其他容器）占用的。而docker中的进程可能把所有资源吃光，这样一来宿主机上面的进程就得不到资源而产生问题。所以需要对容器中的进程进行资源限制。此时需要用到的技术就是Cgroups。 Linux Cgroups 的全称是 Linux Control Group。它最主要的作用，就是限制一个进程组能够使用的资源上限，包括 CPU、内存、磁盘、网络带宽等等。 Cgroups 还能够对进程进行优先级设置、审计，以及将进程挂起和恢复等操作。 在 Linux 中，Cgroups 给用户暴露出来的操作接口是文件系统，即它以文件和目录的方式组织在操作系统的 /sys/fs/cgroup 路径下。 ``` $ mount -t cgroup cpuset on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cpu on /sys/fs/cgroup/cpu type cgroup (rw,nosuid,nodev,noexec,relatime,cpu) cpuacct on /sys/fs/cgroup/cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct) blkio on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) memory on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) ... ``` 在 /sys/fs/cgroup 下面有很多诸如 cpuset、cpu、 memory 这样的子目录，也叫子系统。而在子系统对应的资源种类下，就可以看到该类资源具体可以被限制的方法。比如，对 CPU 子系统来说，可以看到如下几个配置文件，这个指令是： ``` $ ls /sys/fs/cgroup/cpu cgroup.clone_children cpu.cfs_period_us cpu.rt_period_us cpu.shares notify_on_release cgroup.procs cpu.cfs_quota_us cpu.rt_runtime_us cpu.stat tasks ``` cfs\_period 和 cfs\_quota两个参数需要组合使用，可以用来限制进程在长度为 cfs\_period 的一段时间内，只能被分配到总量为 cfs\_quota 的 CPU 时间。 需要在对应的子系统下面创建一个目录，比如，我们现在进入 /sys/fs/cgroup/cpu 目录下： ``` root@ubuntu:/sys/fs/cgroup/cpu$ mkdir container root@ubuntu:/sys/fs/cgroup/cpu$ ls container/ cgroup.clone_children cpu.cfs_period_us cpu.rt_period_us cpu.shares notify_on_release cgroup.procs cpu.cfs_quota_us cpu.rt_runtime_us cpu.stat tasks ``` 这个目录就称为一个“控制组”。你会发现，操作系统会在你新创建的 container 目录下，自动生成该子系统对应的资源限制文件。现在，我们在后台执行这样一条脚本： ``` $ while : ; do : ; done & [1] 226 ``` 显然，它执行了一个死循环，可以把计算机的 CPU 吃到 100%，根据它的输出，我们可以看到这个脚本在后台运行的进程号（PID）是 226。这样，我们可以用 top 指令来确认一下 CPU 有没有被打满： ``` $ top %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 ``` 在输出里可以看到，CPU 的使用率已经 100% 了（%Cpu0 :100.0 us）。 而此时，我们可以通过查看 container 目录下的文件，看到 container 控制组里的 CPU quota 还没有任何限制（即：-1），CPU period 则是默认的 100 ms（100000 us）： ``` $ cat /sys/fs/cgroup/cpu/container/cpu.cfs_quota_us -1 $ cat /sys/fs/cgroup/cpu/container/cpu.cfs_period_us 100000 ``` 接下来，我们可以通过修改这些文件的内容来设置限制。比如，向 container 组里的 cfs\_quota 文件写入 20 ms（20000 us）： ``` $ echo 20000 > /sys/fs/cgroup/cpu/container/cpu.cfs_quota_us ``` 它意味着在每 100 ms 的时间里，被该控制组限制的进程只能使用 20 ms 的 CPU 时间，也就是说这个进程只能使用到 20% 的 CPU 带宽。 接下来，我们把被限制的进程的 PID 写入 container 组里的 tasks 文件，上面的设置就会对该进程生效了： ``` $ echo 226 > /sys/fs/cgroup/cpu/container/tasks ``` 可以用 top 指令查看一下： ``` $ top %Cpu0 : 20.3 us, 0.0 sy, 0.0 ni, 79.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st ``` 可以看到，计算机的 CPU 使用率立刻降到了 20%（%Cpu0 : 20.3 us）。 除 CPU 子系统外，Cgroups 的每一个子系统都有其独有的资源限制能力，比如： * blkio，为​​​块​​​设​​​备​​​设​​​定​​​I/O 限​​​制，一般用于磁盘等设备； * cpuset，为进程分配单独的 CPU 核和对应的内存节点； * memory，为进程设定内存使用的限制。 Linux Cgroups就是一个子系统目录加上一组资源限制文件的组合。而对于 Docker 等 Linux 容器项目来说，它们只需要在每个子系统下面，为每个容器创建一个控制组（即创建一个新目录），然后在启动容器进程之后，把这个进程的 PID 填写到对应控制组的 tasks 文件中就可以了。而至于在这些控制组下面的资源文件里填上什么值，就靠用户执行 docker run 时的参数指定了，比如这样一条命令： ``` $ docker run -it --cpu-period=100000 --cpu-quota=20000 ubuntu /bin/bash ``` 在启动这个容器后，我们可以通过查看 Cgroups 文件系统下，CPU 子系统中，“docker”这个控制组里的资源限制文件的内容来确认： ``` $ cat /sys/fs/cgroup/cpu/docker/5d5c9f67d/cpu.cfs_period_us 100000 $ cat /sys/fs/cgroup/cpu/docker/5d5c9f67d/cpu.cfs_quota_us 20000 ``` 这就意味着这个 Docker 容器，只能使用到 20% 的 CPU 带宽。 **容器技术中一个非常重要的概念，即：容器是一个“单进程”模型。** 由于一个容器的本质就是一个进程，用户的应用进程实际上就是容器里 PID=1 的进程，也是其他后续创建的所有进程的父进程。这就意味着，**在一个容器中，没办法同时运行两个不同的应用，除非我们能事先找到一个公共的 PID=1 的程序来充当两个不同应用的父进程，这也是为什么很多人都会用 systemd 或者 supervisord 这样的软件来代替应用本身作为容器的启动进程**。 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://camelgemonion.gitbook.io/docker/docker-overview/ge-li-yu-xian-zhi.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.