2017，Mesos和kubernetes

我想要聊聊Mesos和Kubernetes，这两者已经达到了很高的成熟度，今年有很多与之相关的博文。我坚定地认为，下一年里，它们的使用增长会更快，因此是时候回顾总结，为2016年做好准备了。本文我想讨论Mesos和Kubernetes的现状，并且列举出优势和劣势，让大家能够理解集群管理器的概念。
Mesos和Kubernetes在开始之前，我想花时间粗略比较一下Mesos和Kubernetes。这样的比较并不容易，因为Mesos做的工作和Kubernetes并不完全一致。要理解这其中的原因，需要快速深入了解一下Mesos和Kubernetes是如何工作的。
Mesos是基于两阶段调度的集群管理器。高度简化来说，Mesos用来管理集群资源，并且向其提供高层级的能接受这些资源来启动任务的“框架”。
相反，Kubernetes是基于Borg背后的理念而设计的集群管理器。Google的集群管理器没有两阶段调度的概念。
介绍Mesos时，我通常会介绍整个Mesos“堆栈”，因为我发现仅仅介绍Mesos会很不准确：如前所述，基于其两阶段调度特性，用户需要能够使用Mesos的“Mesos框架”（比如，Marathon，Aurora，Singularity），才能够像Kubernetes调度器那样工作。使用带有企业支持的Mesos管理集群的流行（付费）方案是DCOS。
除了两阶段调度，Mesos和Kubernetes还有很多区别，比如它们的依赖（Zookeeper、Etcd等等）以及使用方式。本文并不想讨论Mesos和/或Kubernetes的内部细节，因此会直接探讨这两者的优势和劣势。现状、优势和劣势
Mesos和Kubernetes比较清晰的一点是它们处在各自不同的阶段。Mesos由Mesosphere推进，在今年实现了很多成功的里程碑节点，而Kubernetes在七月份才发布了第一个稳定版本。这意味着是使用一个广泛使用的拥有相对长历史的项目产品（Mesos），还是使用一个有光明前途，设计优良的新项目（Kubernetes）。
我可以花几个小时来谈论这两者，但是如果你考虑在集群里使用它们，我认为目前这两者中还没有绝对胜出的方案，因此探讨其中的优势和劣势有助于在具体实践前作为参考。
Mesos 堆栈优势已证实的扩展能力，Apple使用了75000个节点

极度灵活。现在，很多企业在生产环境里使用它，并且有很多不同的Mesos框架可以满足不同的需求。

相对成熟，更容易找到使用其的生产环境用例和最佳实践。

可以使用和docker容器不同的格式。

劣势为不同时代而生，适应于docker容器时代。从一些设计决策看这很明显，包括集群信息以什么方式暴露，通过Json API，实际上相当难用。

语言太多。作为开发人员和运维人员，我想要知道集群里运行的是什么，在发现代码基问题时，我要能够修复问题。要运行Mesos堆栈，涉及到很多组件：Mesos（C++）、Marathon（Scala）、Mesos-DNS（Golang）等等。不太容易找到对这么多语言都熟悉的开发人员。

所有调度器都没有很好地针对微服务进行抽象，就像Pod、Service、Namespace的抽象那样。这些很容易实现，但是还没有实现。

Kubernetes优势设计相当精良的API。

Pod，Service，Namespace是微服务的正确抽象。

充满活力，快速推进的社区。

一种语言，Golang。

劣势还很年轻，会遇到bug。

还没有有名的大公司大规模使用。Google本身还在使用BORG，而在撰写本文时，迁移到Kubernetes的很多公司还没有大型生产集群。

只支持Docker（撰写本文时）

结论很多人在谈论这两种技术，认为关于谁是最好的集群管理器的竞争，还没有明显的结论。如果想要使用集群管理器，我强烈建议Mesos和Kubernetes都试一试，因为这两者中有待学习的地方都很多，在用于生产环境之前，你可能想两个都有所了解。让我们期待2016年会真正成为Kubernetes的成熟之年，能够真正用于生产环境，同时也期待看到Mesos生态系统会如何反击这一强大的竞争对手。