17611538698
webmaster@21cto.com

聊聊调度框架,K8S、Mesos、Swarm 一个都不能少

资讯 0 2105 2017-08-24 12:01:51
b84W7LbUQ8usVunzqWHK.png


Swarm、Mesos、和Kubernetes都为各种规模的企业提供了全面的支持,如何选择是好?

API
目前找到符合企业自身需求的调度框架比较困难,Docker Swarm、Mesos、Kubernetes三大巨头之间最大的区别在可扩展性方面,Swarm的 Zero To Dev 快速设置功能拥有巨大的优势,Docker API的灵活性让它易于集成,并允许使用其他工具,如定制脚本或编写的自定义接口以及复杂的调度。

Swarm:易于集成和设置,灵活的API,有限的定制

Kubernetes:高度通用,开源、

Mesos:适用于大型系统

Kubernetes和Mesos在定制方面都比较通用,不过对于用户的友好度偏低,如果正在集成或更改其中一个就不得不从头开始,不适合相对较小的团队。

可伸缩性&弹性

在可伸缩性和弹性方面,Mesos对于运行着大规模集群的公司来说是最好的选择,在模拟测试中,其最高可以运行5万多个节点,Kubernetes和Swarm都被限制在1000个节点(大约5万个容器)。同时Mesos在大规模解决方案实践上拥有强大的话语权,如Twitter这样的大公司都在使用。


Swarm:适合中小型系统,在这个范畴它的价值和可扩展性最好

Kubernetes:适合中等规模高度冗余的系统

Mesos:目前最稳定的平台,适合大规模系统

于中型企业来说,Kubernetes在多主机集群中具有可靠性和较强的容错力,不过成本较高,因为应用插件的数量越多,就需要越好的安全方案,然而Kubernetes在AWS的覆盖上存在问题,所以很多人会在选择时犹豫不决。

在这三种调度框架做出选择需要进行验证:根据应用的工作方式,数量、以及如何管理数据等基础,可以帮助缩小选择范围。下面在容器存储架构方面对三者进行比较:

存储架构
容器在应用的可移植性方面远远超出了虚拟机所能达到的程度,虚拟机监控应用对硬件有一定的要求,实现应用可移植性的能力要依赖容器之间的相互操作,即便使用云计算应用存储也是一个关键的组件:应用可以利用持久性的存储平台,并围绕它的一些特性进行开发。
容器安装和运行时对存储服务进行特定的请求,以实现如:创建/删除、检查/列表、连接/分离、挂载/卸载等功能。这导致了解决容器“存储问题”的一些独特的尝试与分歧,将存储编排到外部平台的API请求有两种可能:

一个 In-Tree Driver 在容器编配器中构建的本地代码

一个使用插件的Out-Tree Driver

这两者各有利弊,In-Tree收到容器编配程序的发布周期限制,Out-Of-Tree插件可能无法提供与容器协调器绑定的增强特性集。

/uploads/fox/24103115_0.png
Docker

Docker1.7通过创建Docker 容量驱动程序接口来解决外部存储问题,在1.13版本中将商店引入,UNIX插件可以通过在/run/docker/插件的目录进行查找,这是使用Out-Of-Tree的例子之一。

UNIX文件必须在相同的Docker主机上运行,而带有规范或Json文件的插件如果指定了远程URL可以在不同的主机上运行,该接口通过HTTP接受Json/rpc,Out-Of-Tree的接口为Docker CLI提供了完整的存储卷生命周期和编排功能。

Mesos

在Mesos V0.23之前,它支持本地存储, Mesos-Module-Dvdi 为解决这个问题应运而生,随后它的特性出现在上游,现在Mesos 1.0+中也可以使用。该模块利用名为DVECLI的项目,将Docker存储卷驱动程序CLI打包为Mesos,可以使用任何一个Docker存储卷应用和Mesos容器使用,与Docker类似,它也使用了Json,允许框架与DVDCLI对话,并使用HTTP/rpc来与Docker存储卷驱动接口进行对话。

和Docker CLI一样,它也有相同的功能和限制。

Kubernetes

Kubernetes的独特之处在于它兼容In-Tree和Out-Of-Tree,In-tree驱动是Kubernetes的本地代码,是其标准的一部分,这些驱动程序会根据Kubernetes提供的接口公开API命令,如挂载/卸载、创建/删除等等,Kuberneters执行这些功能,实现Pod的创建,并向驱动程序执行特定的API调用执行所需的操作,这也可以利用Kubernetes的特性,如动态配置和存储,缺点是,会过于依赖发布周期,可能需要3-6个月的时间等待修复和持续维护或重新建立代码。

Out-Of-Tree驱动程序使用Flexvolume接口,允许用户编写自己的驱动程序,并在Kubernetes中添加对其存储卷的支持,供应商应该在存储卷插件路径:usr/libexec kubernetes kubelete-plugins/volume/exec/<vendor~driver>/。

这让驱动程序可以在核心的Kubernetes代码之外运行,特性更新和BUG修复也能在自己的时间表上发布,Flexvolume接口期望在其外部发生存储卷创建和删除操作,因此,只有连接/分离和挂载/卸载能力可用,而不是整个存储卷的生命周期。

下图可以看到其不同之处:

/uploads/fox/24103115_1.jpg
存储供应商需要创建多个集成,支持跨容器的生态系统,容器存储接口(CSI)项目正处于早期阶段,但这将是存储和容器成功的关键性因素。
/uploads/fox/24103115_2.jpg
如何选取最适合自身团队的调度框架,以下几点可以参考:

如果想更好的构建和打包应用,或想加速微服务的话,Docker容器和开发工具是最好的选择

若是DevOps团队,且想构建专用于Docker编排的系统,在人员和时间充足的情况下,选择Kubernetes最合适

想建立运行多个任务可靠的平台,且需要较强的可移植性那么Mesos比K8S和Docer的优势更加明显

 
/uploads/fox/24103115_3.jpg
 
 

原    文:Container Storage Architectures: How Does Kubernetes, Docker, and Mesos Compare?
译    文: 数人云


评论