Docker 与 k8s 的恩怨情仇（三）—后浪 Docker 来势汹汹

[GrapeCityChina]

转载请注明出处：葡萄城官网，葡萄城为开发者提供专业的开发工具、解决方案和服务，赋能开发者。

上一节我们为大家介绍了 Cloud Foundry 等最初的 PaaS 平台如何解决容器问题，本文将为大家展示 Docker 如何解决 Cloud Foundry 遭遇的一致性和复用性两个问题，并对比分析 Docker 和传统虚拟机的差异。

Docker 相比于 Cloud Foundry 的改进

利用“Mount Namespace”解决一致性问题

在本系列文章的第一节中，我们提到 Docker 通过 Docker 镜像（ Docker Image ）功能迅速取代了 Cloud Foundry，那这个 Docker 镜像到底是什么呢，如何通过为不同的容器使用不同的文件系统以解决一致性问题？先卖个关子，我们先来看看上一节中说过隔离功能和 Namespace 机制。

Mount Namespace，这个名字中的“Mount”可以让我们想到这个机制是与文件挂载内容相关的。Mount Namespace 是用来隔离进程的挂载目录的，让我们可以通过一个“简单”的例子来看看它是怎么工作的。

（用 C 语言开发出未实现文件隔离的容器）

上面是一个简单的的 C 语言代码，内容只包括两个逻辑： 1.在 main 函数中创建了一个子进程，并且传递了一个参数 CLONE_NEWNS，这个参数就是用来实现 Mount Namespace 的； 2.在子进程中调用了 /bin/bash 命令运行了一个子进程内部的 shell 。

让我们编译并且执行一下这个程序：

gcc -o ns ns.c ./ns

这样我们就进入了这个子进程的 shell 中。在这里，我们可以运行 ls /tmp 查看该目录的结构，并和宿主机进行一下对比：

（容器内外的 /tmp 目录）

我们会发现两边展示的数据居然是完全一样的。按照上一部分 Cpu Namespace 的结论，应该分别看到两个不同的文件目录才对。为什么？

容器内外的文件夹内容相同，是因为我们修改了 Mount Namespace 。Mount Namespace 修改的是进程对文件系统“挂载点”的认知，意思也就是只有发生了挂载这个操作之后生成的所有目录才会是一个新的系统，而如果不做挂载操作，那就和宿主机的完全一致。

如何解决这个问题，实现文件隔离呢？我们只需要在创建进程时，在声明 Mount Namespace 之外，告诉进程需要进行一次挂载操作就可以了。简单修改一下新进程的代码，然后运行查看：

（实现文件隔离的代码和执行效果）

此时文件隔离成功，子进程的 /tmp 已经被挂载进了 tmpfs （一个内存盘）中了，这就相当于创建了完全一个新的 tmp 环境，因此子进程内部新创建的目录宿主机中已经无法看到。

上面这点简单的代码就是来自 Docker 镜像的实现。Docker 镜像在文件操作上本质是对 rootfs 的一次封装，Docker 将一个应用所需操作系统的 rootfs 通过 Mount Namespace 进行封装，改变了应用程序和操作系统的依赖关系，即原本应用程序是在操作系统内运行的，而 Docker 把“操作系统”封装变成了应用程序的依赖库，这样就解决了应用程序运行环境一致性的问题。不论在哪里，应用所运行的系统已经成了一个“依赖库”，这样就可以对一致性有所保证。

利用“层”解决复用性问题

在实现文件系统隔离，解决一致性问题后，我们还需要面对复用性的问题。在实际使用过程中，我们不大可能每做一个镜像就挂载一个新的 rootfs，费时费力，不带任何程序的“光盘”也需要占用很大磁盘空间来实现这些内容的挂载。

因此，Docker 镜像使用了另一个技术：UnionFS 以及一个全新的概念：层（ layer ），来优化每一个镜像的磁盘空间占用，提升镜像的复用性。

我们先简单看一下 UnionFS 是干什么的。UnionFS 是一个联合挂载的功能，它可以将多个路径下的文件联合挂载到同一个目录下。举个“栗子”，现在有一个如下的目录结构：

（使用 tree 命令，查看包含 A 和 B 两个文件夹）

A 目录下有 a 和 x 两个文件，B 目录下有 b 和 x 两个文件，通过 UnionFS 的功能，我们可以将这两个目录挂载到 C 目录下，效果如下图所示：

mount -t aufs -o dirs=./a:./b none ./C

（使用 tree 命令查看联合挂载的效果）

最终 C 目录下的 x 只有一份，并且如果我们对 C 目录下的 a 、b 、x 修改，之前目录 A 和 B 中的文件同样会被修改。而 Docker 正是用了这个技术，对其镜像内的文件进行了联合挂载，比如可以分别把 /sys，/etc,/tmp 目录一起挂载到 rootfs 中形成一个在子进程看起来就是一个完整的 rootfs，但没有占用额外的磁盘空间。

在此基础上，Docker 还自己创新了一个层的概念。首先，它将系统内核所需要的 rootfs 内的文件挂载到了一个“只读层”中，将用户的应用程序、系统的配置文件等之类可以修改的文件挂载到了“可读写层”中。在容器启动时，我们还可以将初始化参数挂载到了专门的“init 层”中。容器启动的最后阶段，这三层再次被联合挂载，最终形成了容器中的 rootfs 。

（ Docker 的只读层、可读写层和 init 层）

从上面的描述中，我们可以了解到只读层最适合放置的是固定版本的文件，代码几乎不会改变，才能实现最大程度的复用。比如活字格公有云是基于.net core 开发的，我们将其用到的基础环境等都会设计在了只读层，每次获取最新镜像时，因为每一份只读层都是完全一样的，所以完全不用下载。

Docker 的“层”解释了为什么 Docker 镜像只在第一次下载时那么慢，而之后的镜像都很快，并且明明每份镜像看起来都几百兆，但是最终机器上的硬盘缺没有占用那么多的原因。更小的磁盘空间、更快的加载速度，让 Docker 的复用性有了非常显著的提升。

Docker 容器创建流程

上面介绍的是 Docker 容器的整个原理。我们结合上一篇文章，可以总结一下 Docker 创建容器的过程其实是：

• 启用 Linux Namespace 配置；
• 设置指定的 Cgroups 参数；
• 进程的根目录
• 联合挂载各层文件

题外：Docker 与传统虚拟机的区别

其实 Docker 还做了很多功能，比如权限配置，DeviceMapper 等等，这里说的仅仅是一个普及性质的概念性讲解，底层的各种实现还有很复杂的概念。具体而言，容器和传统的虚拟机有啥区别？

其实容器技术和虚拟机是实现虚拟化技术的两种手段，只不过虚拟机是通过 Hypervisor 控制硬件，模拟出一个 GuestOS 来做虚拟化的，其内部是一个几乎真实的虚拟操作系统，内部外部是完全隔离的。而容器技术是通过 Linux 操作系统的手段，通过类似于 Docker Engine 这样的软件对系统资源进行的一次隔离和分配。它们之间的对比关系大概如下：

（ Docker vs 虚拟机）

虚拟机是物理隔离，相比于 Docker 容器来说更加安全，但也会带来一个结果：在没有优化的情况下，一个运行 CentOS 的 KVM 虚拟机启动后自身需要占用 100~200MB 内存。此外，用户应用也运行在虚拟机里面，应用系统调用宿主机的操作系统不可避免需要经过虚拟化软件的拦截和处理，本身会带来性能损耗，尤其是对计算资源、网络和磁盘 I/O 的损耗非常大。

但容器与之相反，容器化之后的应用依然是一个宿主机上的普通进程，这意味着因为虚拟化而带来的损耗并不存在；另一方面使用 Namespace 作为隔离手段的容器并不需要单独的 Guest OS，这样一来容器额外占用的资源内容几乎可以忽略不计。

所以，对于更加需要进行细粒度资源管理的 PaaS 平台而言，这种“敏捷”和“高效”的容器就成为了其中的佼佼者。看起来解决了一切问题的容器。难道就没有缺点吗？

其实容器的弊端也特别明显。首先由于容器是模拟出来的隔离性，所以对 Namespace 模拟不出来的资源：比如操作系统内核就完全无法隔离，容器内部的程序和宿主机是共享操作系统内核的，也就是说，一个低版本的 Linux 宿主机很可能是无法运行高版本容器的。还有一个典型的栗子就是时间，如果容器中通过某种手段修改了系统时间，那么宿主机的时间一样会改变。

另一个弊端是安全性。一般的企业，是不会直接把容器暴露给外部用户直接使用的，因为容器内可以直接操作内核代码，如果黑客可以通过某种手段修改内核程序，那就可以黑掉整个宿主机，这也是为什么我们自己的项目从刚开始自己写 Docker 到最后弃用的直接原因。现在一般解决安全性的方法有两个：一个是限制 Docker 内进程的运行权限，控制它值能操作我们想让它操作的系统设备，但是这需要大量的定制化代码，因为我们可能并不知道它需要操作什么；另一个方式是在容器外部加一层虚拟机实现的沙箱，这也是现在许多头部大厂的主要实现方式。

小结

Docker 凭借一致性、复用性的优势战胜了前辈 Cloud Foundry 。本文介绍了 Docker 具体对容器做的一点改变，同时也介绍了容器的明显缺点。下一篇文章，我们会为大家介绍 Docker 又是如何落寞，而后 Docker 时代，谁又是时代新星。敬请期待。