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

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

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

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

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

如果想更好的构建和打包应用，或想加速微服务的话，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