聊聊调度框架,K8S、Mesos、Swarm 一个都不能少
聊聊调度框架,K8S、Mesos、Swarm 一个都不能少
数人云 发表于2个月前
聊聊调度框架,K8S、Mesos、Swarm 一个都不能少
  • 发表于 2个月前
  • 阅读 6
  • 收藏 0
  • 点赞 0
  • 评论 0

腾讯云实验室 1小时搭建人工智能应用,让技术更容易入门 免费体验 >>>   

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插件可能无法提供与容器协调器绑定的增强特性集。

Markdown

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接口期望在其外部发生存储卷创建和删除操作,因此,只有连接/分离和挂载/卸载能力可用,而不是整个存储卷的生命周期。

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

Markdown

存储供应商需要创建多个集成,支持跨容器的生态系统,容器存储接口(CSI)项目正处于早期阶段,但这将是存储和容器成功的关键性因素。

Markdown

如何选取最适合自身团队的调度框架,以下几点可以参考:

如果想更好的构建和打包应用,或想加速微服务的话,Docker容器和开发工具是最好的选择 若是DevOps团队,且想构建专用于Docker编排的系统,在人员和时间充足的情况下,选择Kubernetes最合适 想建立运行多个任务可靠的平台,且需要较强的可移植性那么Mesos比K8S和Docer的优势更加明显

原文作者:Kendrick Coleman 原文链接:https://blog.codedellemc.com/2017/06/27/container-storage-architectures-kubernetes-docker-mesos-compare/?utm_source=tuicool&utm_medium=referral

共有 人打赏支持
粉丝 9
博文 47
码字总数 128689
×
数人云
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: