Mesos容器引擎的架构设计和实现解析

本文讲的是Mesos容器引擎的架构设计和实现解析【编者的话】提到容器，大家第一时间都会想到Docker，毕竟Docker是目前最为流行的容器开源项目，它实现了一个容器引擎（Docker engine），并且为容器的创建和管理、容器镜像的生成、分发和下载提供一套非常便利的工具链，而它的容器镜像格式几乎就是业界的事实标准。但其实除了Docker之外，在容器的开源生态圈中还有其它一些项目也在做自己的容器引擎，这样的项目一般也被称作为容器运行时（container runtime），比如：CoreOS的rkt和Mesos的容器引擎（Mesos containerizer）。

在本文中，我将对Mesos容器引擎进行一个全面的介绍，解释在Docker如此流行的情况下Mesos为什么还要坚持做自己的容器引擎，介绍Mesos容器引擎的总体架构和各核心组件，以及它对容器各相关标准规范的采纳和支持。

容器和容器引擎的定义

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

图 1

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

1. Cgroups（Control Cgroups，控制群组）：Linux中的Cgroups包含多个不同的子系统，如：CPU、memory、device等。通过这些子系统就可以对容器能够使用的各种资源进行限定，比如：通过CPU子系统可以限定容器使用CPU资源的相对权重和单位时间内能够使用的的CPU时间。
2. Namespace（命名空间）：Linux同样支持多个namespace，如：mount、network、pid等。通过这些namespace可以对容器进行不同维度的资源隔离，比如：通过mount namespace可以让容器具有自己独立的挂载空间，在主机或别的容器中发生的挂载事件对该容器就不可见，反之亦然。通过network namespace可以让容器具有自己独立的网络协议栈，而不必和其所在主机共用同一个网络协议栈。
3. 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，而这种做法的问题是：

1. 稳定性不足：Mesos常常会被用来管理几千甚至上万节点的生产环境，而在如此大规模的生产环境中，稳定性是极其重要的。而在这样的环境中，通过实测我们发现Docker engine的稳定性是有所不足的，有时会出现停止响应甚至一些莫名其妙的bug，而这样的问题反映到Docker社区中后有时又无法及时得到解决。这就促使了Mesos的开发者开始设计和实现自己的容器引擎。
2. 难于扩展：Mesos的用户常常会提出一些和容器相关的新需求（比如：让容器能够使用GPU资源，通过CNI配置容器的网络，等等），而这些需求都受限于Docker engine的实现，如果Docker社区拒绝采纳这些需求，或有完全不同的实现方式，那Mesos作为Docker engine之上的调用方也无计可施。

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

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

Mesos容器引擎的总体架构和核心组件

首先我们来看一下Mesos的总体架构，以及容器引擎在其中的位置。 

图 2

上图2中蓝色部分是Mesos自身的组件，可以看到Mesos是典型的Master + Agent架构。Master运行在Mesos集群中的管理节点上，可以有多个（一般设置为三个、五个等奇数个），它们相互之间通过Zookeeper来进行leader选举，被选举成leader的master对外提供服务，而其他master则作为leader master的备份随时待命。Master之上可以运行多个计算框架，它们会调用master提供的API发起创建任务的请求。Master之下可以管理任意多个计算节点，每个计算节点上都运行一个Agent，它负责向Master上报本节点上的计算资源，并接受master下发的创建任务的请求，将任务作为容器运行起来。而Agent内部的一个组件containerizer就是用来管理容器的生命周期的（包括：容器的创建/更新/监控/销毁），它就是Mesos的容器引擎。

我们再来进一步看一下Mesos容器引擎内部的总体架构和核心组件。 

图 3

如上图所示，Meoss容器引擎内部包含了多个组件，主要有：Launcher、Provisioner（其内部又包含了store和backend两个组件）和Isolator。下面来逐一介绍这些组件的主要功能和用途。

Launcher

Launcher主要负责创建和销毁容器，由于容器的本质其实就是主机上的进程，所以launcher在其内部实现上，主要就是在需要创建容器时，调用Linux系统调用fork()/clone()来创建容器的主进程，在需要销毁容器时，调用Linux系统调用kill()来杀掉容器中的进程。Launcher在调用clone()时根据需要把容器创建在其自己的namespace中，比如：如果容器需要自己的网络协议栈，那launcher在调用clone()时就会加入CLONE_NEWNET的参数来为容器创建一个自己的network namespace。

Launcher目前在Mesos中有两种不同的实现：Linux launcher和Posix launcher，上面提到的就是Linux launcher的实现方式，Posix launcher适用于兼容Posix标准的任何环境，它主要是通过进程组（process group）和会话（session）来实现容器。在Linux环境中，Mesos Agent会默认启用Linux launcher。

Provisioner

为了支持基于镜像文件创建容器，Mesos为其容器引擎引入了Provisioner。这个组件完成的主要工作是通过store组件来下载和缓存指定的镜像文件，通过backend组件基于指定的镜像文件来部署容器的根文件系统。

Store

Mesos容器引擎中目前已经实现了Appc store和Docker store，分别用来支持Appc格式的镜像和Docker镜像，此外，Mesos社区正在实现OCI store以支持符合OCI（Open Container Initiative）标准格式的镜像。所以基本上，针对每种不同的镜像文件格式，Mesos都会去实现一个对应的store。而以后当OCI镜像格式成为业界容器镜像文件的标准格式时，我们可能会考虑在Mesos容器引擎中只保留一个OCI store。

Store下载的镜像会被作为输入传给backend来去部署容器的根文件系统，且该镜像会被缓存在agent本地的工作目录中，当用户基于同一镜像再次创建一个容器时，Store就不会重复下载该镜像，而是直接把缓存中的镜像传给backend。

Backend

Backend的主要工作就是基于指定镜像来部署容器的根文件系统。目前Mesos容器引擎中实现了四个不同的backend：

1. AUFS：AUFS是Linux中的一种分层文件系统。AUFS backend就是借助这种分层文件系统把指定镜像文件中的多个分层挂载组合成一个完整的根文件系统给容器使用。基于同一镜像文件创建出来的多个容器共享相同的只读层，且各自拥有独立的可写层。
2. Overlay：Overlay backend和AUFS backend非常类似，它是借助Overlayfs来挂载组合容器的根文件系统。Overlayfs也是一种分层文件系统，它的原理和AUFS类似， 所以，AUFS backend所具备的优点Overlay backend都有，但不同的是Overlayfs已经被Linux标准内核所接受，所以，它在Linux平台上有更好的支持。
3. Copy：Copy backend的做法非常简单，它就是简单地把指定镜像文件的所有分层都拷贝到一个指定目录中作为容器的根文件系统。它的缺点显而易见：基于同一镜像创建的多个容器之间无法共享任何分层，这对计算节点的磁盘空间造成了一定的浪费，且在拷贝镜像分层时也会消耗较大的磁盘I/O。
4. Bind：Bind backend比较特殊，它只能够支持单分层的镜像。它是利用bind mount这一技术把单分层的镜像以只读的方式挂载到指定目录下作为容器的根文件系统。相对于Copy backend，Bind backend的速度更快（几乎不需要消耗磁盘I/O），且多个容器可以共享同一镜像，但缺点就是只能支持单分层镜像，且根文件系统是只读的，如果容器在运行时需要写入数据，就只能通过额外挂载外部卷的方式来实现。

在用户没有指定使用某种backend的情况下，Mesos Agent在启动时会以如下逻辑来自动启用一种backend：

1. 如果本节点支持Overlayfs，启用Overlay backend。
2. 如果本节点不支持Overlayfs但支持AUFS，启用AUFS backend。
3. 如果OverlayFS和AUFS都不支持，启用Copy backend。

由于Bind backend的局限性较大，Mesos Agent并不会自动启用它。

Isolator

Isolator负责根据用户创建容器时提出的需求，为每个容器进行指定的资源限定，且指引launcher为容器进行相应的资源隔离。目前Mesos内部已经实现了十多个不同的isolator，比如：cgroups isolator通过Linux cgroups来对容器进行CPU、memory等资源的限定，而CNI isolator会指引launcher为每个容器创建一个独立network namespace以实现网络隔离，并调用CNI插件为容器配置网络（如：IP地址、DNS等）。

Isolator在Mesos中有着非常好的模块化设计，且定义了一套非常清晰的API接口让每个isolator可以根据自己所需要完成的功能去有选择地实现。这套isolator接口贯穿容器的整个生命周期，Mesos容器引擎会在容器生命周期的不同阶段通过对应的接口来调用isolator完成不同的功能。下面是一些主要的Isolator接口：

• prepare()：这个接口在容器被创建之前被调用，用来完成一些准备性的工作。比如：cgroups isolator在这个接口中会为容器创建对应的cgroups。
• isolate()：这个接口在容器刚刚被创建出来但还未运行时被调用，用来进行一些资源隔离性的工作，比如：cgroups isolator在这个接口中会把容器的主进程放入上一步创建的cgroups中以实现资源隔离。
• update()：当容器所申请的资源发生变化时（如：容器在运行时申请使用更多的CPU资源），这个接口会被调用，它用来在运行时动态调整对容器的资源限定。
• cleanup()：当容器被销毁时这个接口会被调用到，用来进行相关的清理工作。比如：cgroups isolator会把之前为容器创建的cgroups删除。

借助于这种模块化和接口标准化的设计，用户可以很方便地根据自己的需求去实现一个自己的isolator，然后将其插入到Mesos agent中去完成特定资源的限定和隔离。

Mesos容器引擎对容器标准规范的支持

容器这项技术在近几年来飞速发展，实现了爆炸式的增长。但就像任何一种成熟的技术一样，在度过了“野蛮生长期”后，都需要制定相应的规范来对其进行标准化，让它能够持续稳定地发展。容器技术也不例外，目前已知的容器相关的标准规范有：

1. OCI（Open Container Initiative）：专注于容器镜像文件格式和容器生命周期管理的规范，目前已经发布了1.0的版本。
2. CNI（Container Network Interface）：专注于容器网络支持的规范，目前已经发布了0.6.0版本。
3. CSI（Container Storage Interface）：专注于容器存储支持的规范，目前还在草案阶段。

标准规范带来的益处是显而易见的：

1. 对于终端用户：标准化的容器镜像和容器运行时能够让用户不必担心自己被某个容器引擎所“绑架”，可以更加专注于对自身业务和应用的容器化，更加自由地去选择容器引擎。
2. 对于网络/存储提供商：标准规范中定义的网络/存储集成接口把容器引擎的内部实现和不同的网络/存储解决方案隔离开来，让各提供商只需实现一套标准化接口就可以把自己的解决方案方便地集成到各个容器引擎中去，而不必费时费力地去逐个适配不同的容器引擎。

Mesos容器引擎在设计和实现之初，就持有拥抱和采纳业界标准规范的态度，是最早支持CNI的容器引擎之一，且目前正在积极实现对OCI镜像规范的支持。CSI目前正在由Mesos社区和Kubernets社区一起主导并逐步完善，待CSI逐渐成熟后，Mesos容器引擎自然会第一时间支持。日后，作为同时支持三大标准规范的容器引擎，Mesos容器引擎自然会更好地服务上层应用框架和终端用户，同时更加完善地支持各种主流网络/存储解决方案。

原文链接：Mesos容器引擎的架构设计和实现解析

作者：张乾，目前就职于Mesosphere，担任Mesosphere中国区研发负责人。国内首位Apache Mesos committer，专注于各种容器相关的开源技术。

原文发布时间为：2017-09-19

本文作者：张乾

本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。

原文标题：Mesos容器引擎的架构设计和实现解析