大话DC/OS（Mesos），Kubernetes和Docker

Posted 2021-04-16 Mesosphere APAC

互联网中出现很多文章，也有很多社交和所谓的“大仙”喋喋不休在宣称懂各种关系。可以说大部分人都在讲之间的竞争关系，其实不然。当然表面上看这四个开源项目正在为容器而战。您可能也会被一些负面消息所影响，纠结在选择中。此文旨在分析四个开源项目的各自位置/定位，以及为选择困难者提供有价值参考。为了“正义”，消灭“邪恶”。

四种开源技术其实可以归结到三个开源技术，那就是DC/OS（Mesos）、Kubernetes（K8S）和Docker。因为DC/OS是Mesos和一些运维组件的集合物。

我们先从0开始，慢慢道来。。。。

什么是容器呢？其实要了解容器，最好要知道什么是虚拟机，原因是进化的结果。虚拟机就是在一个物理机上利用特定的虚拟化软件，比如VMware、KVM或者Xen等虚拟出若干的操作系统。虚拟机（Virtual Machine）指通过软件模拟并具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统，大白话，就是说在物理机器上先有一个宿主机（Host OS）， 在虚拟出来若干虚拟机，每个虚拟机是一个操作系统，可以是一个Linux或者Windows。大家的共识在虚拟化好处是：资源利用率高、提升效率、简化运维、节省成本等。但是个人感觉对于终端用户好像比单独用物理机多了各种成本，也增加了复杂度。原因是多了很多不确定性，宿主机出问题怎么解决？虚拟机还是过于底层，只是提供操作系统而已。也就是说最终用户不关心底层操作系统。

那么，客户最终关心的是什么？是否能够快速把自己应用快速推向市场？是否能够简化IT运维和使用？是否能够节省成本？是否能够把现有资源利用率提到最高？等等。看起来虚拟化并没有完全最终解决用户需求。此时，容器出现了。容器从架构上，比虚拟机更加轻量、更快、更省、更高效。

以Docker公司为代表的容器技术，大行其道。这里有Mesos容器还有很多其它基于OCI为标准的容器实现。大话时间：以快递食物为例，用容器，其实就像一个现实版的快递员在摩托车后装食物的“容器”，轻量级、速度快、效率高、省钱等。虚拟机就好比用“大象”去拖了。当然，重要环节是，如何能够把资源很好的利用好，并有效的投递，这个就是资源调度和资源管理系统了。不至于让快递小哥到处乱跑，耗时耗力。此时，以DC/OS为代表的调度和资源管理系统就是应运而生，当然K8S和Docker Swarm也算其中，但是随着Docker拥抱K8S，可以说，Docker已经放弃Docker Swarm了。容器一定离不开调度系统和资源管理器。

当然还有一个概念是容器编排，大白话：也就是容器部署和管理。虽然很多技术都可以对容器部署和管理，但实际上他们会解决不同的问题。稍微来定技术，以下是DC/OS和其他相关技术架构图。

其中各种技术之间是相互融合和并重叠发展的，让我们重新审视每个项目细节以及它们如何相互补充和交互的。

先开始说说Docker

Docker开始是一家名为dotCloud的初创公司。故事是，dotCloud团队发现管理众多应用程序和客户业务的依赖关系和二进制文件需要付出巨大精力和时间。 因此，他们将Linux中的cgroups等的一些功能组合到一个简单易用的软件包中，以便应用程序能够足够独立并可以在任何基础架构上运行。大话时间：容器技术是通过“隔板技术”实现了应用和资源的逻辑隔离，就是共享经济下的共享空间，这样相对来说，粒度更小、代价更低、利用率更高。

Docker镜像是一个包，它提供了以下功能：

1. 将应用程序和依赖库包封装在一个包（Docker Image）中，因此应用程序可以在很多异构环境中无缝运行，并不依赖任何外部组件；

2. 提供类似于Git的语义，如“docker Pull”，“docker commit”，以便应用程序开发人员能够轻松快速采用新技术并将其融入到其现有工作流程中；并可以轻松实现Devops工作机制；

3. 将Docker镜像定义为“胶囊”，从而实现混合基础架构无缝运行。任何提交的更改将作为单独的只读胶囊层进行存储，以便重新使用此镜像和跟踪其更改。通过仅传输其更新物而不是整个镜像，胶囊层的实现方式还可节省磁盘空间和网络流量；大话时间：大葱/洋葱一样，层层分明，每一层可以替换，要吃一点，就剥去一层。还可以说现在的计算机都是模块化的，如果一个硬盘坏了，只需要那个硬盘去修，不用搬整个机器了。

Docker很受欢迎的原因是，开发人员可以轻松把运行在笔记本电脑上的容器应用迁移到生产环境中并快速运行起来。大话时间：其实这个是源于开发人员的癖好，什么方便就用什么，越省力，越好。敢问那个码农，没有COPY&PASTE自己开发50%的代码，你来找我哈哈。Docker迎合开发者的嗜好是关键。还有一个概念，用来协调这些容器跨多个机器的部署工具，称为容器编排。有趣的是，支持Docker镜像的第一个容器编排器之一（2014年6月）是Apache Mesos上的Marathon（下面详述）。就在那一年，Docker的创始人兼首席技术官Solomon Hykes还将Mesos推荐为“生产级集群的标杆”。 不幸的是，就在今年早期，Solomon和Docker公司分道扬镳，奔向自由。不久之后，除了Mesos上的Marathon之外，还出现了许多容器编排技术：Nomad，Kubernetes和Docker Swarm（现在现实意义上已经被抛弃），Docker被迫走向K8s。

早前，Docker将软件及其依赖关系封装在一个软件包中的想法已经近乎成为软件行业的规则变更者，Docker文件格式也差点成为行业标准。近些年，领先的容器技术供应商（包括Mesosphere，Google，Pivotal，Docker等）组建了云原生计算基金会（CNCF）和Open Container Initiative（OCI）现实版的容器格式标准。CNCF和OCI旨在确保跨容器技术的互操作性和标准化接口，并确保使用任何工具构建的任何容器都可以在任何引擎上或基础架构上运行。从某种意义上，Docker也渐渐失去了统治力。

再说说Kubernetes（K8s）

Google很早就认识到Docker技术的巨大潜力，并试图在Google云平台上提供容器编排即服务的能力。谷歌在容器方面拥有丰富的经验（他们在Linux中引入了cgroup），但其内部容器技术和分布式计算工具（如Borg）直接与其基础设施深度绑定，不能自拔。因此，谷歌并没有使用现有系统中的任何代码，而是从头开始设计了Kubernetes来编排Docker容器，并把Kubernetse贡献给了CNCF，换句话说，没有任何一家公司对K8s具有完全控制权，也没有什么原厂之说。大家一直在争论Openstack和VMware的模式，可以看到Openstack已经从单纯的技术变成了”政治角斗场“，请问谁是最大受益者？我相信大家都知道，基金会。当然不可否认，VMware走下坡路并不代表模式问题，更像是技术的更新换代。对于国内公司，不管大小都一蜂拥到K8s，不管懂还是不懂，都说了解K8s。想请问当年Linux的盛行，请问最终有几个公司能够真正理解Linux原理，又有多少公司能够处理Linux核心问题？还是要冷静坐下来思考一下，到底自己要的什么，自己真的适合吗？ 不要走向再次”羊群效应“，人云亦云，不懂装懂。

Kubernetes于2015年2月发布，其目标和考量如下：

• 为应用程序开发人员提供一个用于Docker容器编排的强大工具，而无需与底层基础架构直接进行交互；

• 提供标准的部署接口和标志定义以实现跨云平台统一的应用部署体验和API接口；

• 基于模块化API核心，供应商可以将核心Kubernetes技术集成到系统中。

截至2016年3月，谷歌捐赠Kubernetes给CNCF，Google和Mesosphere都是该项目的主要贡献者（紧随其后的是Redhat（Openshift），CoreOS等）。

Kubernetes对于应用程序开发人员非常有吸引力，因为其简化了开发团队和运营团队工作方式，也能让研发人员更加关注其代码本身开发。集成商也喜欢Kubernetes，因为它提供了一种简单的方法来管理容器生命周期。最具吸引力的是Kubernetes其平台本身安装比较简洁，并文档非常完整并易读，还有因为是开源的。

从技术本身说，Kubernetes的核心优势是为应用程序开发人员提供强大的工具来编排无状态的容器，也就是微服务。 虽然有很多想法将其项目范围扩展到更多有状态（如数据分析和有状态数据服务，比如数据库、消息队列等），但这些项目仍处于早期阶段，而且是否能成功还有待观察。就像OpenStack也开始玩容器，能算成功吗？Kubernetes也在多种场合表示愿意和Mesosphere在有状态方面深度合作，其在上次MesosCon也已经成功官宣。为相互合作，打下来坚定基础。说白了，大家还是相互合作大于竞争，术业有专攻。

最后说说DC/OS

DC/OS可以说是Apache Mesos和Apache Marathon及其一系列运维工具的集合。Apache Mesos最初是作为UC Berkeley项目创建的，旨在创建下一代集群管理器，并从云计算，分布式计算基础架构（如Google的Borg和Facebook的Tupperware）中汲取了经验教训。Borg和Tupperware是拥有整块架构，并且是与物理基础设施深度绑定的闭源专有技术，但Mesos引入了模块化架构，也是一种开源开发的产物，并且为完全独立于底层基础架构而设计。在Mesos出现后，Mesos很快被Twitter，Apple（Siri），Yelp，Uber，Netflix以及许多领先的技术公司支持，在中国， 中国联通、中国移动、中国电信、中石化、中石油、三一、爱奇艺、小米、今日头条等都把Mesos应用于生产系统多年，并被应用到从微服务、大数据分析、实时分析等各种场景中，并对有状态和无状态分布式应用做到无缝弹性扩展。请参考生态报告：

作为一个集群管理者，Mesos被设计为解决一系列不同问题：

将数据中心资源抽象为一个资源池，以简化资源分配和配置，同时在私有云或公共云中提供一致的应用程序和操作体验。大白话，就是多种资源被融合到一台笔记本，是不是更加简洁、方便、有效。

• 所有的分布式系统和应用在相同的基础架构（如大数据分析，无状态微服务，分布式数据服务和传统应用程序）上，并能整合各种工作负载，以提高资源利用率并降低各种成本；

• 自动化二天运维操作，针对应用特定的任务（如部署，自我修复，扩展和升级）提供高度可用的容错基础设施；

• 提供常青（evergreen）的可扩展性，在运行新的应用程序时，无需修改集群管理，或任何建立在其上的现有应用程序;

• 应用程序按需自动和底层基础设施集成，从几个节点集群弹性扩展到数十个，甚至数万个节点。管理人员无限做任何手工操作，一切都是根据业务需求，弹性扩所容。

Mesos具有先天的独特性和唯一性，并可单独管理各种工作负载 - 包括传统应用程序，如Java，无状态容器微服务（包括UCR和Docker容器），批处理作业，实时分析和有状态分布式数据服务等。 Mesos工作负载高覆盖率来源于其二层架构，可实现“应用感知”和“按需分配”调度。应用程序“按需分配”是通过将特定于应用程序的操作逻辑封装在“Mesos框架”（分布式系统和Mesos的适配器，通俗说是一个窗口）来完成的。资源管理器Mesos Master在保持隔离的同时提供这些框架的部分底层基础架构。这种方法允许每个工作负载（分布式应用）都拥有自己的专用应用程序调度器，以了解其部署，扩展和升级的具体操作要求。应用程序调度程序也是独立开发，管理和更新的，允许Mesos高度可扩展，支持新的工作负载或随着时间的推移添加更多的操作功能。就像Spark、Cassandra、Kafka等每个都有自己的资源调度方式和自身生命周期管理方式，不能够一视同仁。相当与，每个分布式系统需要有自己的大脑去支配自己的任务，这样才会发挥最大效能，如果用别人的大脑，将会无法控制和失去管理。

举个例子，一个团队是如何管理升级的。一般情况下，无状态应用程序可以从“蓝/绿”部署方法中受益；当旧应用程序仍在运行时，应用程序的另一个完整版本即将启动并运行，并且在新应用准备就绪和旧应用程序被销毁时，客户请求可以无缝切换到新应用程序。但是一些有状态或者分布式系统，比如：升级HDFS或Cassandra等有状态的数据工作负载时，需要逐个节点操作，并使节点逐个脱机，并保留本地数据卷以避免数据丢失，按照特定顺序就地升级，在升级之后在每种节点上执行特殊的命令去检查。以上这么多步骤都是分布式程序独有的或服务特定的，甚至可能是特定于某个版本的。这使得一般传统容器编排调度程序来管理有数据服务变得不可能完成。当然Cassandra也可以部署到K8s，但是其不能够发挥Cassandra本身集群的特征，也就是说上面那些复杂步骤不可能实现。

Mesos以其独特的处理方式管理每个工作负载，所以许多公司已经将Mesos作为一个统一的平台来同时运行微服务和有数据服务。

需要澄清的

想要强调的是，这里并没有提到任何有关容器编排都使用Apache Mesos。那么为什么大家会自动将Mesos与容器编排联想到一起？其实容器编排是可以在Apache Mesos的模块化体系结构之上运行的一个工作负载（框架）的示例，框架名为Marathon，它是Mesos之上的专用容器编排“框架”。 Marathon最初是为了在cgroup容器中编排应用程序归档（如JAR，tarball，ZIP文件）而开发的，并且是2014年首批支持Docker容器的容器编排器之一。

因此，当人们将Docker和Kubernetes与DC/OS或者Mesos进行比较时，他们实际上应该将Kubernetes和Docker Swarm与运行在Mesos上的Marathon进行比较。但是回到今天，由于Docker的选择，其实就回归到了Kubernetes和DC/OS里的Marathon进行对比了。

为什么把这个解释清楚很重要？因为Apache Mesos坦率的说不在乎它上面运行着是什么框架。Mesos可以在共享基础设施架构上弹性地为Java应用服务器，Docker容器编排（Marathon或者K8s）、Jenkins CI作业、Apache Spark分析、Apache Kafka流、机器学习（Tensorflow）等数百个分布式应用及其传统应用提供集群服务。

DC/OS（Mesos）的另一个被大多数公司考虑的原因（它同时对许多企业架构师来说也很有吸引力）是它在运行关键任务工作负载方面的成熟度，也就是企业级。Mesos已经在大规模生产集群中被验证，已经超过7年，而且最大单体集群物理机数目超过60,000。

还在纠结选择吗？

接下来通过场景让您的判断更加准确，而不是继续纠结。

DC/OS(Mesos)、Kubernetes技术都与Docker容器有关，您可以通过容器编排以实现应用程序的可移植性、扩展性和弹性。那么您应该如何选择它们呢？如果您正在寻找现代方式构建和打包应用程序、快速交付应用、敏捷管理应用或准备加速微服务化公司的应用，那么容器应该是最佳方式。Docker有可能是一个选择，但是基于OCI标准的容器，都应该是可以被考虑的容器实现。

如果您是研发或者Devops团队并且希望构建专门针对容器编排的系统，并且愿意将自己的解决方案与底层基础架构集成在一起（或者依赖公共云基础架构，如AWS或Azure容器服务），Kubernetes是一个最好的技术选择，marathon也可以考虑。

如果您想构建一个现在或者未来运行多个关键任务工作负载（包括Docker容器，传统应用程序（例如Java等）和分布式数据服务（例如Spark，Kafka，Cassandra，Elastic））的高可用的企业级平台，并且是跨私有云和共有云的混合云，那么DC/OS（Mesos）是您的最好选择。

在有， 不管你是大型企业还是中小型企业，你首先关注的是快速上一个技术。但是作为决策者来说，您应该更多的考虑出现问题谁来解决问题，业务系统无中断服务等，这个才是关键所在。

最后，一些所谓的“江湖郎中”，在做K8s和DC/OS（Mesos）比较的时候，说到DC/OS（Mesos）太重，我坦白说，DC/OS是解耦不够。难道支持的场景多就是重吗？请大家不要人云亦云。欢迎愿意把这个讲清楚的人来拍砖，红包伺候。

招聘信息：

Mesosphere正在招聘： 架构师、售前、销售、开发等，不限区域。简历请发至 [e-mail]。