e-works数字化企业网  »  文章频道  »  基础信息化  »  云计算和虚拟化

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

2017/10/10    来源:极客头条    作者:张乾      
关键字:Mesos  容器引擎  
提到容器,大家第一时间都会想到Docker,毕竟Docker是目前最为流行的容器开源项目,它实现了一个容器引擎(Docker engine),并且为容器的创建和管理、容器镜像的生成、分发和下载提供一套非常便利的工具链。
    容器和容器引擎的定义
 
    首先我们来了解一下什么是容器。我个人对容器的定义是:一个或一组使用了cgroups做资源限定、使用了namespace做资源隔离、且使用了的镜像文件做根文件系统的进程。如下图1所示:
 
Mesos容器引擎的架构设计和实现解析
 
    图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镜像创建出容器。
 
    Mesos容器引擎的总体架构和核心组件
 
    首先我们来看一下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容器引擎内部的总体架构和核心组件。 
 
Mesos容器引擎的架构设计和实现解析
 
    图3
 
    如上图所示,Meoss容器引擎内部包含了多个组件,主要有:launcher、provisioner(其内部又包含了store和backend两个组件)和isolator。下面来逐一介绍这些组件的主要功能和用途。
 

责任编辑:李欢
本文为授权转载文章,任何人未经原授权方同意,不得复制、转载、摘编等任何方式进行使用,e-works不承担由此而产生的任何法律责任! 如有异议请及时告之,以便进行及时处理。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
兴趣阅读
相关资料
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐