当前位置 : 主页 > 网络编程 > 其它编程 >

聊聊调度框架,K8S、Mesos、Swarm

来源:互联网 收集:自由互联 发布时间:2023-07-02
Swarm、Mesos、和Kubernetes都为各种规模的企业提供了全面的支持,如何选择是好?API目前找到符合企业自身需求的调度框架比较困难,DockerSwarm、Mesos Swarm、Mesos、和Kubernetes都为各种规模的
Swarm、Mesos、和Kubernetes都为各种规模的企业提供了全面的支持,如何选择是好?API目前找到符合企业自身需求的调度框架比较困难,DockerSwarm、Mesos 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.pngDocker

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//。

这让驱动程序可以在核心的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?译    文: 数人云

【文章原创作者:滨海网站制作 http://www.1234xp.com/binhai.html 复制请保留原URL】
上一篇:rtmpdump代码简单分析
下一篇:没有了
网友评论