转载

Docker vs. Kubernetes vs. Apache Mesos：为什么你知道的可能都是错的

有无数的文章、议题和大量的社交聊天中都会将Docker、Kubernetes和Mesos进行比较。如果你也从中了解过，你会认为这三个开源项目正在为争夺容器的霸主地位而战。你可能也会觉得，只选择其中一个技术，这会是一个谨慎的决定；当然也有一些人为了支持他们所选择的技术而去否认其他两种技术。显然，这些做法都是不对的。尽管这三种技术都能实现容器部署、管理和扩展应用程序，但实际上它们各自解决了不同的问题，并且应用于完全不同的环境中。事实上，这三种被广泛采用的技术，没有一种与其他是完全相同的。与其比较这些快速发展的技术重叠特性，不如让我们回顾一下每个项目的原始任务、体系结构以及它们如何相互补充和相互作用的。

让我们先从Docker开始

Docker Inc是一家名为dotCloud的平台服务初创公司。其团队发现，在许多应用程序和客户之间的管理依赖关系和二进制文件里需要付出巨大的努力。因此，他们将Linux cgroups和命名空间的一些功能组合到一个单一且易于使用的包中，这样应用程序就可以在任何基础设施上持续运行。这个包是Docker镜像，它提供以下功能：

• 将应用程序和库打包在单个包中（Docker镜像），因此应用程序可以一致地部署在许多环境中 • 提供诸如“docker push”、“docker commit”等类似于“docker”的语义，让开发人员可以轻松地采用新技术，并将其集成到现有工作流中 • 将Docker镜像定义为不可变层，支持不可变基础结构。已提交的更新会存储为一个单独的只读层，这使得重用镜像和跟踪更改变得很容易。层之间还能通过传输更新而不是传输整个镜像，来节省磁盘空间和网络流量 • 通过实例化不可变的镜像运行Docker容器，它使用一个可写层临时存储运行时的变动，从而可以快速部署和扩展应用程序的多个实例。

Docker越来越受欢迎，开发人员开始从在笔记本电脑上运行，转变为在生产模式中运行这些容器。同时，需要额外的工具在多个机器之间协调这些容器，这被称为容器编排。有趣的是，第一个支持Docker镜像（2014年6月）的容器支持器之一是Apache Mesos上的Marathon （将在下面详细介绍）。那一年，Docker的创始人兼首席技术官Solomon Hykes推荐Mesos为“生产集群的黄金标准”。不久之后，除了Docker Swarm的Marathon之外，许多容器编排技术也出现了：Nomad、Kubernetes和Mesos（现在是Docker引擎的一部分）。随着Docker将开源文件格式商业化，该公司也开始推出工具，以补充核心Docker文件格式和运行引擎，包括：

• Docker hub，用于Docker镜像的公共存储 • Docker registry，用于存储本地部署 • Docker cloud，一种用于构建和运行容器的管理服务 • Docker datacenter ，作为一项商业服务，体现了许多Docker技术

Docker将软件及其依赖包封装在单个包中，这对软件行业来说是一个游戏规则的改变；同样的方式，mp3也帮助重塑了音乐产业。Docker文件格式成为行业标准，领先的容器技术供应商（包括Docker、Google、Pivotal、Mesosphere以及其他）形成了Cloud Native Computing Foundation （CNCF）和Open container Initiative（OCI）。今天，CNCF和OCI的目标是确保跨容器技术的互操作性和标准化接口，并确保使用任何工具构建的Docker容器能够在任何时间或基础设施上运行。

Enter Kubernetes

Google在早期就意识到了Docker镜像的潜力，并希望在Google云平台上提供“as-a-service”的服务。谷歌在容器方面有丰富的经验（他们在Linux中引入了cgroups），但现有的内部容器和分布式计算工具，如Borg，会直接与他们的基础设施连接。因此，谷歌没有使用现有系统中的任何代码，而是从零开始设计了Kubernetes来编排Docker容器。Kubernetes于2015年2月发布，包含以下目标和注意事项：

• 授权应用程序开发人员使用Docker容器提供的强大工具，而无需与底层基础设施进行交互 • 为一致的应用程序部署和跨云的api提供标准的部署接口和原语 • 构建一个模块化的API核心，允许供应商围绕核心的Kubernetes技术集成系统。到2016年3月，谷歌将Kubernetes捐赠给了CNCF，它到今天为止仍然是该项目的主要贡献者（其次是Redhat、CoreOS以及其他）。

Kubernetes对应用程序开发人员来说，非常有吸引力，因为它减少了对基础设施和操作团队的依赖。厂商也喜欢Kubernetes，因为它提供了一种简单的方式来支持容器移动，并为运行自己的Kubernetes部署的操作提供了一个商业解决方案（这仍然是一个不平凡的经验）。Kubernetes也是很有吸引力的，因为它是CNCF下的开源项目，与Docker集群相比，后者的开源项目受到Docker公司的严格控制。 Kubernetes的核心优势在于为应用程序开发人员提供了强大的工具，用于编排无状态的Docker容器。尽管计划扩展更多的工作负载范围（例如分析和状态数据服务），但是这些计划仍然处于非常早期的阶段，并且还有待观察它们的成功程度。

Apache Mesos

Apache Mesos最初是加州大学伯克利分校的一个项目，目的是创建下一代集群管理器，并且有来自云计算、分布式计算基础设施中学习的经验，比如谷歌的Borg和Facebook的Tupperware。虽然Borg和Tupperware有单一的体系结构，而且是与物理基础设施相关的封闭的专有技术，但Mesos引入了一种模块化的体系结构，一种开源的开发方法，并被设计为完全独立于底层的基础设施。Mesos很快被Twitter、苹果（Siri）、Yelp、优步、Netflix等许多领先的科技公司所接受，涉及到很多领域，从微服务、大数据和实时分析等。作为一个集群管理器，Mesos的架构是为了解决一系列不同的难题：

• 将数据中心资源抽象为单个池，以简化资源分配，同时提供跨私有或公共云的一致应用程序和操作经验 • 在相同的基础设施上使用不同的工作负载，比如分析、无状态的微服务、分布式数据服务和传统应用程序，以提高利用率，降低成本和占用空间 • 针对特定应用程序的任务，例如部署、自愈、扩展和升级，可以自动执行day-two操作；提供高可用性容错基础设施 • 在不修改集群管理器或任何现有应用程序的基础上，提供用于运行新应用程序和技术的永久可扩展性 • 可弹性地规划应用程序和底层基础设施，从少数几个，到数十个，甚至到数万个。

Mesos具有独特的能力，可以单独管理各种不同的工作负载，包括传统的应用程序，如Java、无状态Docker微服务、批处理工作、实时分析和状态分布式数据服务等。Mesos的广泛工作负载来自于它的两层架构，这使 “application-aware”得以调度。application-aware的调度是通过将特定的应用程序的操作逻辑封装在“Mesos框架”中（类似于操作中的runbook）来完成的。Mesos Master，资源管理器，在保持隔离的情况下，为这些框架提供了一部分底层基础设施。这种方法允许每个工作负载都有自己专用的应用程序调度器，从而可以理解它的部署、扩展和升级的特定操作需求。应用调度程序的开发、管理和更新都是独立的，这也就允许Mesos具有高度的可扩展性，来支持新的工作负载，同时增加更多的操作能力。

举例来说，一个团队如何管理升级程序。无状态应用程序可以从“blue/green”部署方法中获益；这款应用的另一个完整版本在旧版本还存在的时候就会出现，当用户准备好时，打开网络会搜索到新版本，旧应用也就会被覆盖。但是，像HDFS或Cassandra这样进行升级数据工作时，需要将节点离线一次，来保持本地的数据量，避免数据丢失，同时执行一个特定的操作，并在升级之前和之后对每个节点执行特殊的检查和命令。这些步骤中都是需要特定的应用程序或服务的，甚至可能是特定的版本。这使得使用传统的容器来管理数据服务变得异常困难。 Mesos有能力管理每一个工作，这使得许多公司都将Mesos作为一个统一的平台，将微服务和数据服务结合在一起。“SMACK stack”是用于运行数据密集型应用程序的通用参考体系结构。

一个清晰明朗的时刻

我们还没有介绍过Apache Mesos的容器编排该如何描述。那么，为什么人们会自动将Mesos与容器编排联系起来呢？容器编排是可以在Mesos的模块化体系结构上运行的，它使用了一个专门基于Mesos的编排框架，叫做Marathon。Marathon最初是为了在cgroup容器中编排应用程序存档（如jar、tarball、ZIP文件）而开发的，并在2014年成为首批支持Docker容器的容器协调器之一。因此，当人们将Kubernetes和Kubernete与Mesos进行比较时，他们实际上是在把Docker和 Docker Swarm与运行在Mesos上的Marathon进行比较。为什么这很重要?因为坦白地说，Mesos并不关心谁会在它的基础上运行。Mesos可以为Java应用服务器提供集群服务、Docker容器编排、 Jenkins CI Jobs、Apache Spark analytics， Apache Kafka streaming，以及更多的共享基础设施。Mesos甚至可以运行在Kubernetes或其他容器的组合器上，尽管目前公共集成还未实现。

Mesos的另一个优势（以及为什么它对许多企业架构师有吸引力）是它在运行关键任务时的成熟度。Mesos已经在大规模生产（数万台服务器），已经超过7年的时间，这就是为什么我们知道，在市场上，它比其他许多的容器技术更成熟，更可靠。

这些都意味着什么？

总之，这三种技术都与Docker容器有关，并为应用程序的可移植性和规模提供了容器编排。那么如何在他们之间做出选择呢?这要很据当时的工作选择合适的工具（对于不同的工作，是需要选择不同的工具的）。如果您是一名应用程序开发人员，想寻找一种现代的方式来构建和打包应用程序，或者加速微服务，那么Docker容器和开发工具就是最好的选择。如果你是一个dev / devops团队，想要搭建一个系统致力于Docker容器编排，并愿意亲力亲为底层基础设施的集成解决方案（或依赖于公共云基础设施，如谷歌引擎或Azure容器服务），Kubernetes是你值得考虑的好技术。如果您想构建一个可靠的平台，可以运行多个关键任务，包括Docker容器、遗留程序（例如：Java）和分布式数据服务（例如：Spark， Kafka， Cassandra， Elastic），并想要可移植的云服务或数据中心，那么Mesos（或者我们自己的Mesos分布， Mesosphere DC/OS）是适合你的。无论您选择什么，您都将使用一系列工具，这些工具可以更有效地利用服务器资源，简化应用程序的可移植性，并提高开发人员的敏捷性。这样，你真的不太可能出错。