有无数的文章都在讨论和比较Docker、Kubernetes 以及Mesos。如果你是初学者，那么你可能会认为这三个开源项目正为了称霸容器界而殊死搏斗。

虽然这三种技术都使得使用容器部署、管理和伸缩应用成为可能，但实际上它们各自解决了不同的问题，并且根植于迥异的上下文环境中。事实上，这三种被广泛采用的工具链，都是有差别的。

让我们来对三个项目的原始任务、技术架构，以及它们是如何相互补充和交互的来进行对比。

Docker

Docker 公司－始于名为dotCloud 的平台即服务（PaaS）供应商。dotCloud 团队发现，在许多应用和客户之间管理依赖和二进制文件时需要付出大量的工作。因此他们将Linux 的cgroups和namespace 的一些功能合并成一个单一且易于使用的软件包，以便于应用程序可以一致地运行在任何基础设施上。这个软件包就是所谓的Docker 镜像，它提供了如下的功能：

将应用程序和依赖库封装在一个软件包（即Docker 镜像）中，因此应用可以被一致地部署在各个环境上；

提供类似Git 的语义，例如 docker push，docker commit 等命令让应用开发者可以快速接受这门新的技术，并将其融入到现有的工作流中；

定义Docker 镜像为不可变的层，支持不可变的基础设施。新提交的变更被分别保存为只读层，让复用镜像和追踪变更记录变得十分简单。还通过只传输更新而不是整个镜像来节省磁盘空间和网络流量；

通过实例化不可变的镜像和读写层来运行Docker 容器，读写层可以临时地存储运行时变更，从而轻松部署和扩展应用程序的多个实例。

Docker 变得越来越受欢迎，开发者们开始从在笔记本电脑上运行容器转而在生产环境中运行容器。跨多个机器之间协调这些容器需要额外的工具，这称之为”容器编排”。第一个支持Docker 镜像的容器编排工具是Apache Mesos 的marathon。那年，Docker 的创始人兼首席技术官Solomon Hykes 将Mesos 推荐为”生产集群的黄金标准“。不久之后，除了Mesos 的Marathon 之外，还出现了许多的容器编排技术：Nomad、Kubernets，Docker Swarm 。

随着Docker 开始商业化其开源的文件格式，该公司还开始引入工具来完善其核心的Docker 文件格式和运行时引擎，包括：

为公开存储Docker 镜像的而生的Docker hub；

存储私有镜像的Docker 仓库（Docker registry）；

Docker cloud，用于构建和运行容器的管理性服务；

Docker数据中心作为一种商业产品体现了许多Docker 技术；

Docker 将软件及其依赖关系封装在一个软件包中的洞察力改变了软件行业的游戏规则，Docker 文件格式成为行业标准，领先的容器技术供应商（包括Docker、Google、Pivotal、Mesosphere 等） 组建了 CNCF和OCI 。如今，CNCF 和OCI 旨在确保容器技术之间的互操性和标准化接口，并确保使用任何工具构建的任何Docker 容器都可以在任何运行时或基础架构上运行。

Kubernetes

Google 很早就认识到了Docker 的潜力，并试图在Google Cloud Platform （GCP）上提供容器编排“即服务”。Google 在容器方面拥有丰富的经验（是他们在Linux 中引入了cgroups），但现有的内部容器和Borg 等分布式计算工具直接与其基础架构相耦合。所以，Google 没有使用原有系统的任何代码，而是从头开始设计Kubernetes （K8S）来编排Docker 容器。Kubernetes 于2015 年2 月发布，其开发目标包括：

为应用程序开发人员提供编排Docker 容器的强大工具，而无需与底层基础设施交互；

提供标准部署接口。以实现云端一致的应用部署体验和API；

基于模块化API 核心。允许供应商围绕Kubernetes 的核心技术集成其系统。

Kubernetes 对应用程序开发人员非常有吸引力，因为它减轻了对基础架构和运营团队的依赖程度。供应商也喜欢Kubernetes，因为它提供了一个容易的方式来拥抱容器化运动，并为客户部署自己的Kubernetes提供商业解决方案。

Kubernetes 的核心优势是为应用程序开发人员提供了用于编排无状态Docker 容器的强大工具。

Apache Mesos

Apache Mesos应用了从云计算级别的分布式基础架构中习得的经验和教训。并且，Mesos 推出了一种模块化架构，一种开源的开发方法，旨在完全独立于基础架构。Mesos 迅速被Twitter ，Apple ，Yelp ，Netflix和许多领先的技术公司采用，支持从微服务、大数据和实时分析到弹性扩展的一切。

Apache Mesos在设计之初，设定的开发目标如下：

将数据中心资源抽象为单个池来简化资源分配，同时在私有云或公有云中提供一致的应用和运维体验；

在相同的基础架构上协调多个工作负载，如分析、无状态微服务、分布式数据服务和传统应用程序，以提高利用率，降低成本和台面空间；

为应用程序特定的任务（如部署、自我修复、扩展和升级），自动执行第二天的操作；提供高度可用的容错基础设施；

提供持久的可扩展性来运行新的应用程序和技术，而无需修改集群管理器或其上构建的任何现有应用程序；

弹性扩展可以将应用程序和底层基础设施从少量扩展到数十到数万个节点。

Mesos 独有的独立管理各种工作负载的能力—— 包括Java 这样的传统应用程序、无状态Docker 微服务、批处理作业、实时分析和有状态的分布式数据服务。Mesos 广泛的工作负载覆盖来自于其两级架构，从而实现了“应用感知”调度。通过将应用程序特定的操作逻辑封装在“Mesos 框架”中来实现应用程序感知调度。资源管理器Mesos Master 提供了这些框架基础架构的部分，同时保持隔离。这种方法允许每个工作负载都有自己的专门构建的应用程序调度程序，可以了解其部署、扩展和升级的特定操作要求。应用程序调度程序也是独立开发、管理和更新的，这让Mesos 拥有高度可扩展的能力，支持新的工作负载或随着时间的推移而增加更多的操作功能。

Mesos的运行机制是新版本的应用运行起来时，原先旧版本的软件依然还正常运转着，然后当旧应用被销毁时流量将会切换到新的应用上。但是升级数据工作负载例如HDFS 或者Cassandra 要求节点停机一次，此时需要持久化本地数据卷以防止数据丢失，并且按照特定的顺序执行原位升级，在升级之前和升级完成之后，都要在每一个节点类型上执行特定的检查和命令。任何这些步骤都是应用程序或服务特定的，甚至可能是版本特定的。这让使用常规容器编排调度程序来管理数据服务变得非常困难。

总结

三种项目的运行机制和运行目的并不相同，所以当人们将Docker 和Kubernetes 与Mesos 进行比较时，他们实际上是将Kubernetes 和Docker Swarm 与在Mesos 上运行的Marathon 进行比较。

Mesos 坦率地讲并不在乎它上面运行了什么。Mesos 可以在共享的基础设施上弹性地为Java 应用服务器提供集群服务、Docker 容器编排、Jenkins 持续集成任务、Apache Spark 分析、Apache Kafka 流，以及更多其他的服务。Mesos 甚至可以运行Kubernetes 或者其他的容器编排工具。所有这三种技术都与Docker 容器有关，可以让你在容器编排上实现应用程序的可移植性和扩展性。至于选择哪种项目，这主要取决于你的身份。

如果你是一个应用开发人员，正在寻找现代化的方式来构建和打包你的应用程序，或者想加速你的微服务计划，Docker 容器和开发工具就是最好的选择。

如果你是一个开发人员或者DevOps 的团队，并希望构建一个专门用于Docker 容器编排的系统，而且愿意花时间折腾集成解决方案与底层基础设施，Kubernetes 是一个可以考虑的好技术。

如果你想要建立一个运行多个关键任务工作负载的可靠平台，包括Docker 容器、传统应用程序和分布式数据服务，并希望所有这些可依移植到云端提供商或者数据中心，那么Mesos，更适合你们的需求。

互动区

＊ 你对以上内容有什么看法？你最关注云计算哪个趋势？如果你还有想了解的技术话题，欢迎留言分享。

第三十二期 启迪云交付工程师  王中杰