有无数的文章、讨论、以及很多社区喋喋不休地比较 Docker、Kubernetes 和 Mesos。如果你只是听信了只言片语，你可能会认为这三个开源项目正为了称霸容器界而殊死搏斗。你可能还相信从他们中选出一个如宗教信仰般神圣——真正的信徒会忠于他们的信仰，而且会烧死那些敢于考虑替代方案的异教徒。

那都是废话。

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

让我们重新审视每个项目的原始任务、技术架构，以及它们是如何相互补充和交互的，而不是纠结于比较这些快速迭代的技术之间重叠的特性。

让我们从 Docker 开始……

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

• 将应用程序和依赖库封装在一个软件包（即 Docker 镜像）中，因此应用可以被一致地部署在各个环境上；
• 提供类似 Git 的语义，例如 docker push，docker commit 等命令让应用开发者可以快速接受这门新的技术，并将其融入到现有的工作流中；
• 定义 Docker 镜像为不可变的层，支持不可变的基础设施。新提交的变更被分别保存为只读层，让复用镜像和追踪变更记录变得十分简单。层还通过只传输更新而不是整个镜像来节省磁盘空间和网络流量；
• 通过实例化不可变的镜像和读写层来运行 Docker 容器，读写层可以临时地存储运行时变更，从而轻松部署和扩展应用程序的多个实例。

Docker 变得越来越受欢迎，开发者们开始从在笔记本电脑上运行容器转而在生产环境中运行容器。跨多个机器之间协调这些容器需要额外的工具，这称之为容器编排container orchestration。有趣的是，第一个支持 Docker 镜像的容器编排工具（2014 年 6月）是 Apache Mesos 的 Marathon（后面会有详细介绍) 。那年，Docker 的创始人兼首席技术官 Solomon Hykes 将 Mesos 推荐为“生产集群的黄金标准”。不久之后，除了 Mesos 的 Marathon 之外，还出现了许多的容器编排技术：Nomad、Kubernetes，不出所料还有 Docker Swarm （它如今是 Docker 引擎的一部分）。

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

• 为公开存储 Docker 镜像的而生的 Docker hub；
• 存储私有镜像的 Docker 仓库（Docker registry）；
• Docker cloud，用于构建和运行容器的管理性服务；
• Docker 数据中心作为一种商业产品体现了许多 Docker 技术；

来源: www.docker.com

Docker 将软件及其依赖关系封装在一个软件包中的洞察力改变了软件行业的游戏规则，正如 mp3 的出现重塑了音乐行业一般。Docker 文件格式成为行业标准，领先的容器技术供应商（包括 Docker、Google、Pivotal、Mesosphere 等) 组建了 云计算基金会Cloud Native Computing Foundation (CNCF) 和 开放容器推进联盟Open Container Initiative (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 的核心技术集成其系统。

2016 年 3 月，Google 将 Kubernetes 捐赠给了 CNCF，并且直到今天仍然是该项目的主要贡献者（其次是Redhat，CoreOS 等）。

来源: wikipedia

Kubernetes 对应用程序开发人员非常有吸引力，因为它减轻了对基础架构和运营团队的依赖程度。供应商也喜欢 Kubernetes，因为它提供了一个容易的方式来拥抱容器化运动，并为客户部署自己的 Kubernetes（这仍然是一个值得重视的挑战）提供商业解决方案。 Kubernetes 也是有吸引力的，因为它是 CNCF 旗下的开源项目，与 Docker Swarm 相反，Docker Swarm 尽管是开源的，但是被 Docker 公司紧紧地掌控着。

Kubernetes 的核心优势是为应用程序开发人员提供了用于编排无状态 Docker 容器的强大工具。 虽然有多个扩大项目范围的提议，以提供更多的功能（例如分析和有状态数据服务），但这些提议仍处于非常早期的阶段，它们能取得多大的成功还有待观察。

Apache Mesos

Apache Mesos 始于加州大学伯克利分校UC Berkeley的下一代容器集群管理器项目，并应用了从云计算级别的分布式基础架构（如 Google 的 Borg 和 Facebook 的 Tupperware）中习得的经验和教训。 虽然 Borg 和 Tupperware 具有单一的架构，并且是与物理基础架构紧密结合的闭源专有技术，但 Mesos 推出了一种模块化架构，一种开源的开发方法，旨在完全独立于基础架构。Mesos 迅速被 Twitter、Apple（Siri 中）、Yelp、Uber、Netflix 和许多领先的技术公司采用，支持从微服务、大数据和实时分析到弹性扩展的一切。

作为集群管理器，Mesos 被设计用来解决一系列不同的挑战：

• 将数据中心资源抽象为单个池来简化资源分配，同时在私有云或公有云中提供一致的应用和运维体验；
• 在相同的基础架构上协调多个工作负载，如分析、无状态微服务、分布式数据服务和传统应用程序，以提高利用率，降低成本和台面空间;
• 为应用程序特定的任务（如部署、自我修复、扩展和升级），自动执行第二天的操作；提供高度可用的容错基础设施；
• 提供持久的可扩展性来运行新的应用程序和技术，而无需修改集群管理器或其上构建的任何现有应用程序；
• 弹性扩展可以将应用程序和底层基础设施从少量扩展到数十到数万个节点。

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

Mesos two-level scheduler

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

Mesos 以每一个工作负载所需的特定方式管理各种工作负载，使得许多公司将 Mesos 作为一个统一的平台，将微服务和数据服务结合在一起。数据密集型应用程序的通用参考架构是 “SMACK 家族”（LCTT 译注：SMACK 即 Spark、Mesos、Akka、Cassandra、Kafka)。

是时候搞清楚这些了

请注意，我们尚未对 Apache Mesos 的容器编排有任何描述。所以为什么人们会自动地将 Mesos 和容器编排联系起来呢？容器编排是可以在 Mesos 的模块化架构上运行的工作负载的一个例子，它是通过一个专门的编排“框架”来完成的，这个框架就 Marathon，一个构建于 Mesos 之上的工具。 Marathon 最初是为了在 cgroup 容器中编排应用归档（如 JAR、tarball、ZIP 文件）而开发的，是 2014 年最先支持 Docker 容器的编排工具之一。

所以当人们将 Docker 和 Kubernetes 与 Mesos 进行比较时，他们实际上是将 Kubernetes 和 Docker Swarm 与在 Mesos 上运行的 Marathon 进行比较。

为什么搞清楚这一点很重要？ 因为 Mesos 坦率地讲并不在乎它上面运行了什么。 Mesos 可以在共享的基础设施上弹性地为 Java 应用服务器提供集群服务、Docker 容器编排、Jenkins 持续集成任务、Apache Spark 分析、Apache Kafka 流，以及更多其他的服务。Mesos 甚至可以运行 Kubernetes 或者其他的容器编排工具，即使公共的集成目前还不可用。

来源: Apache Mesos 2016 调查问卷

Mesos 的另一个考虑因素（也是为什么它对许多企业架构师来说如此有吸引力）是运行关键任务工作负载的成熟度。 Mesos 已经在大规模生产环境下（成千上万台服务器）运行了超过 7 年的时间，这就是为什么它比市场上许多其他的容器技术更具有生产上的可行性和扩展上的可靠性。

我所说的这些什么意思？

总而言之，所有这三种技术都与 Docker 容器有关，可以让你在容器编排上实现应用程序的可移植性和扩展性。那么你在它们之间如何选择呢？ 归根到底是为工作选择合适的工具（也可能是为不同的工作选择不同的工具）。如果您是一个应用开发人员，正在寻找现代化的方式来构建和打包你的应用程序，或者想加速你的微服务计划，Docker 容器和开发工具就是最好的选择。

如果你们是一个开发人员或者 DevOps 的团队，并希望构建一个专门用于 Docker 容器编排的系统，而且愿意花时间折腾集成解决方案与底层基础设施（或依靠公共云基础架构，如 Google 容器引擎（GCE）或 Azure 容器服务（ACS）），Kubernetes 是一个可以考虑的好技术。

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

无论您选择什么，您都将拥抱一套可以更有效地利用服务器资源的工具，简化应用程序的可移植性，并提高开发人员的敏捷性。你的选择真的不会有错。

via: https://mesosphere.com/blog/docker-vs-kubernetes-vs-apache-mesos/