Mesos容器引擎的架构设计

　　引言：提到容器，大家第一时间都会想到Docker，毕竟Docker是目前最为流行的容器开源项目，它实现了一个容器引擎（Docker engine），并且为容器的创建和管理、容器镜像的生成、分发和下载提供一套非常便利的工具链，而它的容器镜像格式几乎就是业界的事实标准。但其实除了Docker之外，在容器的开源生态圈中还有其它一些项目也在做自己的容器引擎，这样的项目一般也被称作为容器运行时（container runtime），比如：CoreOS的rkt和Mesos的容器引擎（Mesos containerizer）。在本文中，我将对Mesos容器引擎进行一个全面的介绍，解释在Docker如此流行的情况下Mesos为什么还要坚持做自己的容器引擎，介绍Mesos容器引擎的总体架构和各核心组件，以及它对容器各相关标准规范的采纳和支持。

　　容器和容器引擎的定义

　　首先我们来了解一下什么是容器。我个人对容器的定义是：一个或一组使用了cgroups做资源限定、使用了namespace做资源隔离、且使用了的镜像文件做根文件系统的进程。如下图1所示：

　　图1

　　由此可见，实现容器的三大核心技术分别是：

　　Cgroups（Control Cgroups，控制群组）：Linux中的Cgroups包含多个不同的子系统，如：CPU、memory、device等。通过这些子系统就可以对容器能够使用的各种资源进行限定，比如：通过CPU子系统可以限定容器使用CPU资源的相对权重和单位时间内能够使用的的CPU时间。

　　Namespace（命名空间）：Linux同样支持多个namespace，如：mount、network、pid等。通过这些namespace可以对容器进行不同维度的资源隔离，比如：通过mount namespace可以让容器具有自己独立的挂载空间，在主机或别的容器中发生的挂载事件对该容器就不可见，反之亦然。通过network namespace可以让容器具有自己独立的网络协议栈，而不必和其所在主机共用同一个网络协议栈。

　　Layered filesystem（分层文件系统）：Linux中的layered filesystem有多种不同的实现，如：AUFS、overlayfs等。通过这些layered filesystem配合mount namespace就可以快速部署出容器自己独立的根文件系统。而且，基于同一个镜像文件创建出来的多个容器可以共享该镜像文件中相同的只读分层，以达到节省主机磁盘空间的效果。

　　上面这三种技术都是在Linux系统中存在已久且相对成熟的技术，但让终端用户直接使用它们来创建和管理容器显然并不方便。所以，容器引擎就应运而生了，它所做的主要工作就是将这三种技术在其内部有机地结合和利用起来以实现创建容器和管理容器的生命周期，并对外提供友好的接口让用户能够方便的创建和管理容器。Cgroups、namespace和layered filesystem的详细介绍我就不再本文中赘述了，感兴趣的读者可以查阅Linux中这三种技术的相关文档。

　　需要指出的是，容器引擎对这三种技术的使用往往是有选择且可定制的，比如：用户可以通过容器引擎创建一个使用cgroups memory子系统但不使用CPU子系统的容器，这样的容器对内存资源的使用就会受到相应的限定，但对CPU资源的使用则不受任何限定。用户也可以创建一个使用mount namespace但不使用network namespace的容器，这样的容器就会有自己独立的挂载空间，但和主机共用一个网络协议栈。Mesos容器引擎在这方面的可定制化进行得非常彻底，除了上面所说的对cgroups子系统和namespace的定制之外，Mesos容器引擎还能够支持无镜像文件创建容器，这是其它容器引擎所不具备的。

　　Mesos容器引擎产生的背景

　　在Docker如此流行的情况下，Mesos为什么还要坚持做自己的容器引擎呢？其实Mesos在很早期的版本就和Docker进行了集成，用户可以通过Mesos创建一个Docker容器，在内部实现上，Mesos agent会调用Docker的命令行和Docker engine通信，以让其创建Docker容器。这也就是意味着Mesos对容器的管理严重依赖于Docker engine，而这种做法的问题是：

　　稳定性不足：Mesos常常会被用来管理几千甚至上万节点的生产环境，而在如此大规模的生产环境中，稳定性是极其重要的。而在这样的环境中，通过实测我们发现Docker engine的稳定性是有所不足的，有时会出现停止响应甚至一些莫名其妙的bug，而这样的问题反映到Docker社区中后有时又无法及时得到解决。这就促使了Mesos的开发者开始设计和实现自己的容器引擎。

　　难于扩展：Mesos的用户常常会提出一些和容器相关的新需求（比如：让容器能够使用GPU资源，通过CNI配置容器的网络，等等），而这些需求都受限于Docker engine的实现，如果Docker社区拒绝采纳这些需求，或有完全不同的实现方式，那Mesos作为Docker engine之上的调用方也无计可施。

　　众所周知，Mesos的定位是数据中心操作系统，它是一个非常好的通用资源管理和资源调度系统，一开始就是一个“大脑级“的存在，但如果只有“大脑”没有“四肢”（对容器的支持就是“四肢”的一种），或“四肢“掌握在别人手中，那Mesos本身和其生态圈的可持续发展显然是受限的。所以，发展自己的“四肢”是Mesos逐步发展壮大的必然选择。

　　基于上述这些原因，Mesos社区决定要做自己的容器引擎，这个容器引擎完全不依赖于Docker engine（即：和Docker engine没有任何交互），但同时它又完美兼容Docker镜像文件。这也就意味着，用户可以通过Mesos在一台没有安装运行Docker engine的主机上，基于任意Docker镜像创建出容器。