这篇文章给大家介绍如何进行Kubernetes做为Mesos 的Framework的理论分析，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
在寻找容器编排平台时，开源社区提供一些如 Kubernetes、Marathon-Mesos 或 Docker Swarm 等可行的选择。在很多寻找运行在线负载原生云的用户中，Kubernetes 非常受欢迎，因为它内置支持一系列有用的特性，包括自动化部署，负载均衡，自动扩展，滚动升级等等 DevOps 用户寻找的要素。但同时，在考虑企业运行环境的负载范围，处理多个框架间共同关心的问题时则需要一种更通用的资源管理器，而 Apache Mesos 则解决了这个问题。Mesos 是一个轻量的系统，只有230K行的代码，而 Kubernetes 则有1.3M+，它专注于提供一种基础资源抽象层，这样可以按框架来分配资源，处理基于 task 执行能力，同时处理如主机维护模式等管理操作。
在 IBM，我们探索了如何通过将 Kubernetes 作为 Mesos 的一个 Framework 让 Mesos 和 Kubernetes 一起工作。虽然 Mesos 和内置在 Kubernetes 可用资源管理功能有一部分重叠,但依然可以使用这两个工具协同管理。这种模式的一个好处就是不仅有支持一部分类似大数据，Spark 负载的能力，也能让其他的分析系统可以受益于 Mesos 支持的细粒度的资源分配。我们认为在运行高动态的业务负载时这将提升资源的使用和性能。
Mesos 因为是轻量的，可以在生产环境中很容易调度成千上万的节点。另一方面虽然 Kubernetes 在迅速改善的规模和性能，但仍限于1000个节点。可以通过把 Kubernetes 运行在 Mesos，可以提供一个在 Mesos 的基础上运行数倍的 Kubernetes 节点的能力。
Kubernetes 只专注容器，而 Mesos 的目的更多的是在可以支持操作系统进程级别的负载。对企业来说把已存在的业务负载放到一个共同管理的环境更为重要。Kubernetes 允许企业进入一个新的容器化业务负载的原生云，而 Mesos 则是已存在的 Windows、Unix 和Linux 环境的桥梁。
作为探索的一部分，IBM 将率先在把Kubernetes 集成到Mesos 的项目中作出贡献。这里包括设法帮助kube-DNS 与外部的DNS（#28453），提高Kubernetes的调度算法（#31068）,让 Kubernetes 的命名空间可以和 Mesos（#31069）更好的工作，而且支持 Kubernetes 运行在异构硬件环境上（#29901）. 这项工作是额外贡献在 IBM 正在直接执行的 Kubernetes 和 Mesos 项目。
对于如何用一种可消费的方式打包这些技术使普通企业用户为不同的工作负载轻松建立自己的容器管理平台，我们很快会分享更多的信息，请继续关注!
源文连接：Exploring Kubernetes as a Mesos Framework: Does it make sense?
译者说
Mesos 的定义是用于调度成百上千个节点的超大规模集群管理平台，而Kubernetes 的定义是专门用来管理，部署，调度容器化应用的开源系统。2014年6月 Google 宣布 Kubernetes 开源后，同年7月 Google 官方就宣布了和 Mesosphere 的合作，为用户提供可以让 Kubernetes 和其他 Framework（如 Hadoop、Spark、Marathon、Chronos等）共享 Mesos 集群资源的能力。这个合作可以理解成将 Kubernetes 作为 Framework 整合到 Mesosphere 生态系统中。从功能上看，Mesos 自身更像是一个 IaaS 层的资源管理工具，用来为上层框架提供共享底层资源的能力，再通过上面运行 Framework 实现 PaaS 层的应用管理，可以调度和管理不同的 Framework，而 Kubernetesm 则只是一个调度管理容器的 Framework。文章中说 Mesos 只有230K行的代码，而 Kubernetes 则有 1.3M+。Mesos 的代码要比 Kubernetes 少，是因为 Mesos 框架不完整，还需要借助好多其他 “Framework”（比如 Marathon、Aurora、Singularity）才能够像 Kubernetes 那样做调度。两个产品各自有优势，也各自有劣势，这个合作的目的是通过两者的结合进行互补提供一个满足用户更多需求的平台。
虽然这个项目在 Kubernetes 开源后就已经提出来，但两年多过去了，并没有在生产实践中得到有效的落地推广，现在这个项目是 Mesos 社区主导。Mesos 社区贡献代码的主要是 Mesospher、Twitter、IBM 和 Intel，而 Kubernetes on Mesos 这个项目现在主要由 IBM 在推进，Intel 则在最近表示将继续投入资金支持 Mesos 项目。他们认为虽然 Kubernetes 获得了很大的突破，但他们并不认为 Mesos 与 Kubernetes 是竞争者的关系，Kubernetes 是直接面向应用开发者，而 Mesos 则是面向超大规模集群部署，更适合数据中心。就像文章中说的，Kubernetes 目前还只能管理1000个节点，而通过运行在 Mesos 上可以数倍的扩展 Kubernetes 的能力，做一个更大的资源管理平台。Intel 认为 Mesos 的目标是大型数据中心的资源管理和编排，当把 Kubernetes 运行在 Mesos 管理的数据中心上时也将划清楚两者之间的区别。以下为 Kubernetes 在 Mesos 的一个结构图：
图 1 Kubernetes on Meos 来源 GitHub
Kubernetes on Mesos 并不是简单的在 Mesos 平台上运行 Kubernetes，而是要把 Kubernetes 集成到 Mesos 项目里，并解决相应的问题。如文章中提到的 IBM 正在处理的一些issue，如设法帮助 kube-DNS 与外部的 DNS（#28453）等。
那么 Kubernetes 做为 Mesos 的一个 Framework 是否有意义？可以分析一下在生产实践中，两者的结合会有什么优缺点优。
优点：
Mesos 提供在生产环境中运行多个 Framework，当生产环境不仅需要运行容器编排 Kubernetes，还需要运行其他的 Framework 时，这种模式可以让 Kubernetes 和其它 Framework 共享资源，对系统的资源利用率提升有一定帮助。
通过这种模式 Mesos 可以享受 Kubernetes 对微服务的抽象，并实现让一组容器运行在相同的 slave 节点上。
同时 Mesos 可以根据负载自动扩展 Kubernetes 的 Worker 节点，而不需要手动去安装。
Kubernetes 也可以不再受节点数量的限制可以得到数倍的扩展。
然而站在现在这个时间节点上，这个方案缺点也十分明显：
上述提到的优点只有在面对超大型数据中心（10W+物理节点）以上才能体现，但是国内能满足超大集群规模的企业能有几家?而国内 BAT 这样的公司又不使用，都会自己直接开发。
开源生态圈不稳定，本身 Docker 的三种 COEs 还处于发展中，功能都在逐步完善，产品迭代的很快。而且三种 COEs 还存在着竞争的关系，目前结果并不明朗。
技术方案过于复杂，在生产实践中会比只使用一个产品更复杂更重，坑也会更多。两个产品本身就有功能重叠的地方，从某种角度上对用户来讲，这两个还是同类的产品，如果一个也能有满足用户需求，又何必同时用两个搞这么复杂。而且一般企业不会把自己弄这么重，都会是循序渐进的推行一些技术，否则会消化不良。复杂度小，能快速实践是企业在选择新技术落地的关键，太复杂的架构一般企业搞不定，只会导致实践周期变长，会影响长期的稳定性，落地将会变得更难。虽然这种模式功能更全面，但同时也增加了落地的难度，而部分企业在现阶段还不需要这多么的功能，选择单一的产品会适合。
Mesos 是轻量型，代码比 Kubernetes 的要少，但两者的结合又将增加彼此的重量，这是一个矛盾的设定。
Mesos 的架构与现在热门的 Openstack 定位也存在部分功能重叠，这样企业将更不知道如何选择落地方案，那么这种方案的选择度将会很低。
关于如何进行Kubernetes做为Mesos 的Framework的理论分析就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。