Docker与k8s的前世今生，有请下一位容器选手登场（上）

大家在工作中或许或多或少都接触过Docker，那你知道Docker以及容器化背后的原理到底是什么吗？

容器化技术满天下，那为什么只有Docker被大家所熟知呢？

后Docker时代，到底谁才是云原生时代的王者？

我们相信本系列文章能帮您解答这些疑惑。

• Docker与k8s学习资料与笔记传送门

成为PaaS前浪的Cloud Foundry

被“嫌弃”的物理服务器

在云时代以前，开发者如需构建一个线上的站点，必须自己维护物理服务器。但是随着业务发展，大体量服务器逐渐增多，随之而来的是硬件、场地和维护成本的不断提高。对于面向C端的站点来说，网络热点事件具有随机性，流量的变化并不可控，难免会遭遇站内流量暴涨的情况。此时如果没有备用服务器，突发的大流量很可能会冲垮整个站点。但在没有突发事件的时候，备用服务器的采购和维护成本又让人不可忽略。

image

（运维的传统艺能：上线拜祖，图片来自网络）

哪里有问题，哪里就有商机。有人想到，如果买一批服务器放在外网，安排专人管理，然后按照用户的需要租赁出去，不正好解决了这个问题吗？

于是，一场云计算的好戏，正式上演。

虚拟机还是“超重”了

云计算时代的大幕拉开，大厂先后登台，让我们先简单做一下回顾。

• 2006年，亚马逊成立aws，从云端存储业务开始。
• 2008年，云计算初创。
• 2009年，阿里云成立。目前最新的数据表明，2020年度IaaS市场份额调查，阿里云位居全球第三，亚太第一；前两名分别是亚马逊和微软，市场份额达9.5%，超过谷歌的6.1%，亚马逊40.8%，微软17%。国内市场份额40% ，第二是华为云，占18%。
• 2010年，OpenStack由NASA发布。OpenStack是一个IaaS架构，可以用其架构来搭建自己的私有云，让任何人都可以自行创建和提供云计算服务。对比而言，AWS和aliyun都是自研架构，OpenStack是开源的。所以公司如果需要，完全可以接入OpenStack搭建自己的私有云。（当然前提需要有OpenStack核心开发能力）。
• 2010-2013年之间，云计算的全球份额被aws和OpenStack瓜分。

这时的云计算技术，本质都是虚拟化技术，将硬件资源作为基础设施提供给用户，简称IaaS。简单理解，IaaS就是将一个很大的服务器，通过虚拟化技术拆分成多个小的虚拟服务器，提供服务，类似于在本机装了虚拟机。

image

（云计算主力玩家的进场时间，图片来自网络）

但是，IaaS时代的虚拟机还是太过于笨重了。每一台虚拟机都需要消耗CPU、内存等计算资源才能支撑应用的运行。即便应用再小，系统的开销都是固定的成本。如何为IaaS减肥，让虚拟机系统的开销降到最低？

2013年开始，云计算正式进入了PaaS时代。PaaS时代，云计算所销售的单元，从虚拟机变成了应用运行平台。于是，云厂商提供的服务更多，资源利用率也更高了。

什么是PaaS？我们用一个通俗的例子来解释。如果我们现在是一个烧饼店老板，采用IaaS模式意味着我们需要用别人厨房、锅炉、煤气，自己和面做馅料，做烧饼。如果是PaaS，我们烧饼的面粉、馅料和调料都是别人提供好了，我们只需要把饼烤熟。

云厂商该如何构建一套好用的PaaS服务呢？借力开源项目，成为各厂商的共识。

Cloud Foundry开启PaaS开源时代

PaaS的核心是平台。最早出现在开发者视野中的PaaS开源项目中，vmware创立的Cloud Foundry是知名度最高的。与IaaS提供云上虚拟机的服务方式不同，基于Cloud Foundry的云计算能够提供应用托管的功能。开发者只需要通过一条简单的命令比如：cf push "我的应用"，就可以将项目打成一个压缩包，上传到Cloud Foundry服务器。而Cloud foundry会开启自己的调度器，在一群云主机中找到满足用户需求的主机（系统版本、性能、个数），然后通过容器化技术，在主机上创建一个容器，在容器中下载压缩包，解压并运行，最终成为一个对外提供服务的应用。

此外，Cloud Foundry平台对这些应用项目提供分发，灾备，监控，重启等等服务（这也是我们提供给用户的核心服务）。这种托管服务解放了开发者的生产力，让他们不用再关心应用的运维状况，而是专心开发自己的应用。而这就是PaaS的“初心”，平台即服务。

image.png

（Cloud Foundry提供的服务）

这里就会有同学问了，容器是什么？容器是用来解决多个应用资源冲突与隔离性问题的技术。Linux上的namespace机制和cgroups命令都能用做资源隔离和限制，这些都是容器技术。

容器技术并不是Docker创建的，在Docker兴起之前，就已经被其他公司商用了，但是为什么现在一谈起容器，所有人第一时间想到的就是Docker呢？这就要提到Cloud Foundry的死亡。

从Cloud Foundry到Docker

Cloud Foundry似乎已经和我们现在使用的云功能区别不大，但2021年的现实情况却是Cloud Foundry已经死了。

我们看过互联网上很多文章，再结合我们活字格公有云开发的经验，我们认为这个项目的致命缺陷集中它的打包机制上。

Cloud Foundry最核心的组件就是应用的打包和分发机制，也是开发者打交道最多的功能。Cloud Foundry为每一种主流的语言都定义了一套打包的方式，这些方式之间毫无章法。但就是这个打包功能，成了Cloud Foundry的软肋，一直为用户所诟病。开发者不得不为每一种语言，每一种框架，甚至是每个版本应用维护一个打好的包，还有可能出现本机运行成功，打了个包上传上去之后就无法运行的情况。情况最严重的时候，开发者在调试云平台系统上花的时间都已经比开发一个新软件的时间要长了。

本来是为赋能开发者的而生的技术，Cloud Foundry却对开发者如此不友好。当开发者的抱怨积累到一定程度，想要在PaaS浪潮中央站稳脚跟的Cloud Foundry被后起之秀Docker“红牌罚出局”也就顺理成章了。

最初，Docker是一个当时还叫dotCloud的公司（2010年由所罗门海克斯创建，Y Combinator孵化）开发的容器项目。在Cloud Foundry困于打包问题时，Docker正在悄悄积蓄力量，在开源后的短短几个月内就迅速崛起，成为一个不容忽视的PaaS技术方案，吸引了云服务开发者的眼球。

滑稽的是，在Docker刚开源的时候，Cloud Foundry的首席产品经理 James Bayer就在社区做了一次详细的对比，告诉用户Docker和Cloud Foundry一样，都是使用了Namespace和Cgroups技术的沙箱而已，没什么值得关注的。

事实上，Docker也确实就和他所说的一样，采用了这个“传统”的技术方案，但是Docker与Cloud Foundry相比，做了一点小小的创新，体现了所罗门海克斯的远见。从2010他就开始考虑应用打包的一致性与复用性问题，并提出了创新的解决方案，最终对Cloud Foundry造成了毁灭性的打击。这个解决方案就是Docker镜像。

image

（Docker，图片来自官网）

刚开源的Docker迅速爆火，憨态可掬的小鲸鱼，对用户友好的文档，三分钟部署一个Nginx集群的宣传语，以及Docker Image这个 “微不足道的创新”，让Docker席卷整个PaaS领域。

Docker的制胜法宝：镜像

Docker成功的关键，在于Docker镜像几乎完美地解决了Cloud Foundry在打包方面的软肋。

所谓的镜像，其实也是一个压缩包，但是比起Cloud Foundry那种执行文件+启动脚本的打包结果，镜像提供给用户的是一套完整的运行环境，每一个镜像都可以指定操作系统版本，内部可以构建程序执行的文件结构，并且一份镜像可以完全共享在多处使用。

image.png

此外，Docker还给开发者提供了一套完善的镜像制作流程，这套流程与编程语言和框架无关。开发者只需要按照该流程，定制对应程序所需要的运行的操作系统环境即可。

总之，Docker 镜像完美解决了两个问题：

1.本地环境和服务器环境的差异

2.同一份镜像可以让所有的机器进行复用

从这一刻开始，PaaS的市场已经完全是Docker的天下。

用最简单的技术实现“容器”

进程 vs 容器

以Linux操作系统为例，计算机里运行的进程是程序执行之后，从磁盘的二进制文件，到内存、寄存器、堆栈指令等等所用到的相关设备状态的一个集合，是数据和状态综合的动态表现。而容器技术的目标就是对一个进程的状态和数据进行的隔离和限制。可以说，容器的本质其实就是Linux中的一个特殊进程。这个特殊的进程，主要靠Linux系统提供的两个机制来实现，这里先回顾一下。

Namespace

Linux Namespace是Linux内核的一项功能，该功能对内核资源进行分区，以使一组进程看到一组资源，而另一组进程看到另一组资源。该功能通过为一组资源和进程具有相同的名称空间而起作用，但是这些名称空间引用了不同的资源。资源可能存在于多个空间中。此类资源的示例是进程ID，主机名，用户ID，文件名以及与网络访问和进程间通信相关的某些名称。其种类列举如下：

1. Mount namespaces
2. UTS namespaces
3. IPC namespaces
4. PID namespaces
5. Network namespaces
6. User namespaces

超级进程

在Linux操作系统中，PID==1的进程被称为超级进程，它是整个进程树的root，负责产生其他所有用户进程。所有的进程都会被挂在这个进程下，如果这个进程退出了，那么所有的进程都被 kill。

隔离 & 限制

刚才我们提到了隔离和限制，具体指的是什么呢？

隔离

以Docker为例（Cloud Foundry同理，我的机器上没有安装后者），我们可以执行下列的命令创建一个简单的镜像：

$ docker run -it busybox /bin/sh

这条语句执行的内容是：用docker运行一个容器，容器的镜像名称叫busybox，并且运行之后需要执行的命令是/bin/sh，而-it参数表示需要使用标准输入stdin和分配一个文本输入输出环境tty与外部交互。通过这个命令，我们就可以进入到一个容器内部了，分别在容器中和宿主机中执行top命令，可以看到以下结果：

image

（在容器内外执行top语句的返回结果）

从中可以发现，容器中的运行进程只剩下了两个。一个是主进程PID==1的/bin/sh超级进程，另一个是我们运行的top。而宿主机中的其余的所有进程在容器中都看不到了——这就是隔离。

image

（被隔离的top进程，图片来自网络）

原本，每当我们在宿主机上运行一个/bin/sh程序，操作系统都会给它分配一个进程编号，比如PID 100。而现在，我们要通过Docker把这个/bin/sh程序运行在一个容器中，这时候，Docker就会在这个PID 100创建时施加一个“障眼法”，让他永远看不到之前的99个进程，这样运行在容器中的程序就会当自己是PID==1的超级进程。

而这种机制，其实就是对被隔离的程序的进程空间做了手脚，虽然在容器中显示的PID 1，但是在原本的宿主机中，它其实还是那个PID==100的进程。所使用到的技术就是Linux中的Namespace机制。而这个机制，其实就是Linux在创建进程时的一个可选参数。在Linux中，创建一个线程的函数是（这里没写错就是线程，Linux中线程是用进程实现的，所以可以用来描述进程）：

int pid = clone(main_function, stack_size, SIGCHLD, NULL);

如果我们给这个方法添加一个参数比如CLONE_NEWPID：

int pid = clone(main_function, stack_size, CLONE_NEWPID | SIGCHLD, NULL);

那么这个新的进程就会看到一个全新的进程空间，在这个空间里，因为该空间中仅有这一个进程，所以它自己的PID就等于1了。

这样一个过程就是Linux容器最基本的隔离实现了。

限制

光有namespace隔离的容器就和没有电脑的程序员一样，是残缺不全的。

如果我们只隔离不限制，笼子里面的程序照样占用系统资源，访问依旧自由。为了给有了隔离性的程序添加资源限制，就用到了第二个技术：cgroups

cgroups本来是google的工程师在2006年开发的一个程序，全称是Linux Control Group，是Linux操作系统中用来限制一个进程组能使用资源的上限，包括CPU、内存、磁盘、网络带宽等的功能。

通过Cgroups给用户暴露的API文件系统，用户可以通过修改文件的值来操作Cgroups功能。

image.png

（被cgroup限制的进程，图片来自网络）

在Linux系统（Ubuntu）中可以执行以下命令查看CgroupsAPI文件：

mount -t Cgroups

image

（cgroup文件系统）

从上图可以看到，系统中存在包括cpu、内存、IO等多个Cgroups配置文件。

我们以CPU为例来说明以下Cgroups这个功能。对CPU的限制需要引入两个参数cfs_period和cfs_quota，我们为了给活字格公有云Docker内的程序限制CPU时，会经常操作这两个参数。这两个参数是组合使用的，意思是在长度为cfs_period时间内，程序组只能分到总量为cfs_quota的CPU时间。也就是说cfs_quota / cfs_period == cpu使用上限。

要想限制某个进程的CPU使用，可以在/sys/fs/Cgroups/cpu目录下，执行以下命令创建一个文件夹container：

/sys/fs/Cgroups/cpu/ > mkdir container

此时，我们可以发现系统自动在container目录下生成的一系列CPU限制的参数文件，这是Linux系统自动生成的，表示我们成功为CPU创建了一个控制组container：

image

（默认的CPU资源文件列表）

为了展示CPU限制的实际效果，让我们执行一个用以下脚本创建的死循环：

while : ; do : ; done &

我们在top命令结果中会看到返回的进程为398，因为死循环，cpu占用率为100%：

image.png

（死循环的进程占了100% CPU）

这时，我们再看下container目录下的cpu.cfs_quota_us和cpu.cfs_period_us：

image

（默认情况下CPU的限制参数）

这里是没有做过限制时的样子。cfs_quota_us为-1说明并没有限制CPU的运行上限。现在我们改一下这个值：

echo 20000 > /sys/fs/Cgroups/cpu/container/cpu.cfs_quota_us

然后将之前的进程398写入这个控制组的tasks文件中：

echo 398 > /sys/fs/Cgroups/cpu/container/tasks

这时再top一下，发现刚才的死循环的CPU使用率变成20%了，CPU使用资源限制开始生效。

image

（使用cgroup限制CPU使用量的死循环进程）

以上，就是通过Cgroups功能对容器做限制的原理了。同理，我们可以用此方法，对一个进程的内存、带宽等做限制，如果这个进程是一个容器进程，一个资源受控的容器基本就可以展现在你面前了事实上，在云时代的早期，Cloud Foundry等“前浪”都是采用这种方式创建和管理容器。相比于后来者，Cloud Foundry等在容器的隔离和限制上，虽相对简单、易于理解，但在一些场景下难免会受到制约。

这里要做一个特别的说明，只有Linux中运行的容器是通过对进程进行限制模拟出来的结果，Windows和Mac下的容器，都是通过Docker Desktop等容器软件，操作虚拟机模拟出来的“真实”的虚拟容器。

后浪Docker来势汹汹

Docker相比于Cloud Foundry的改进

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

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

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

image

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

上面是一个简单的的C语言代码，内容只包括两个逻辑：

1.在main函数中创建了一个子进程，并且传递了一个参数CLONE_NEWNS，这个参数就是用来实现Mount Namespace的；

2.在子进程中调用了/bin/bash命令运行了一个子进程内部的shell。

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

gcc -o ns ns.c
./ns

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

image

（容器内外的/tmp目录）

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

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

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

image.png

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

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

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

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

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

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

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

image

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

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

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

image.png

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

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

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

image

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

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

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

Docker容器创建流程

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

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

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

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

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

image.png

（Docker vs 虚拟机）

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

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

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

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

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

总结

Docker凭借一致性、复用性的优势战胜了前辈Cloud Foundry。本文介绍了Docker具体对容器做的一点改变，同时也介绍了容器的明显缺点。下一篇文章，我会为大家讲一件云原生时代的闭源落幕、Kubernetes的创新与“容器编排”上演“终结者”大片

都看到这里了，不点个赞这合理吗？这不合理！

以上，下期见，end

参考博主：葡萄城官网：https://home.cnblogs.com/u/powertoolsteam/