Kubernetes架构为什么是这样的？

在 Google 的一篇关于他们内部的 Omega 的调度系统的论文，把调度系统分成三类：单体、二层调度和共享状态三种，按照它的分类方法，通常 Google的 Borg 被分到单体这一类，Mesos 被当做二层调度，而 Google 自己的 Omega 被当做第三类“共享状态”。论文的作者实际上之前也是Mesos的设计者之一，后来去了 Google 设计新的 Omega 系统，并发表了论文，论文的主要目的是提出一种全新的“Shard State”的模式来同时解决调度系统的性能和扩展性的问题，但是实际我觉得 Shared State 模型太过理想化，根据这个模型开发的 Omega 系统，似乎在 Google 内部并没有被大规模使用，也没有任何一个大规模使用的调度系统采是采用 Shared State 模型。

因为Kubernetes的大部分设计是延续 Borg 的，而且 Kubernetes 的核心组件（Controller Manager 和 Scheduler）缺省也都是绑定部署在一起，状态也都是存储在 etcd 里面的的，所以通常大家会把 Kubernetes 也当做“单体”调度系统，实际上我并不赞同。

我认为 Kubernetes 的调度模型也完全是二层调度的，和 Mesos 一样，任务调度和资源的调度是完全分离的，Controller Manager 承担任务调度的职责，而 Scheduler 则承担资源调度的职责。

实际上 Kubernetes 和 Mesos 调度的最大区别在于资源调度请求的方式：

• 主动 Push 方式。是 Mesos 采用的方式，就是 Mesos 的资源调度组件（Mesos Master）主动推送资源 Offer 给 Framework，Framework 不能主动请求资源，只能根据 Offer 的信息来决定接受或者拒绝。

• 被动 Pull 方式。是 Kubernetes 的方式，资源调度组件 Scheduler 被动的响应 Controller Manager的资源请求。

这两种方式所带来的不同，我会主要从下面 5 个方面来分析。另外注意，我所比较两者的优劣，都是从理论上做的分析，工程实现上会有差异，一些指标我也并没有实际测试过。

资源利用率： Kubernetes 胜出

理论上，Kubernetes 应该能实现更加高效的集群资源利用率，原因资源调度的职责完全是由 Scheduler 一个组件来完成的，它有充足的信息能够从全局来调配资源，然后 Mesos 缺却做不到，因为资源调度的职责被切分到 Framework 和 Mesos Master 两个组件上，Framework 在挑选 Offer 的时候，完全没有其他 Framework 的工作负载的信息，所以也不可能做出最优的决策。我们来举一个例子，比如我们希望把对耗费 CPU 的工作负载和耗费内存的工作负载竟可能调度到同一台主机上，在 Mesos 里面不太容易做到，因为他们是属于不同的 Framework。

扩展性： Mesos 胜出

从理论上讲，Mesos 的扩展性要更好一点。原因是 Mesos 的资源调度方式更容易让已经存在的任务调度迁移上来。我来举一个例子说明一下，假设已经有了一个任务调度系统，比如 Spark ，现在要迁移到集群调度平台上，理论上它迁移到 Mesos 比 Kubernetes 上更加容易。

如果迁移到 Mesos ，没有改变它原来的工作流程和逻辑，原来的逻辑是：来了一个作业请求，调度系统把任务拆分成小的任务，然后从资源池里面挑选一个节点来运行任务，并且记录挑选的节点 IP 和端口号，用来跟踪任务的状态。迁移到 Mesos 之后，还是一样的逻辑，唯一需要变化的是那个资源池，原来是自己管理的资源池，现在变成 Mesos 提供的 Offer 列表。

如果迁移到 Kubernetes，则需要修改原来的基本逻辑来适配 Kubernetes，资源的调度完全需要调用外部的组件来完成，并且这个变成异步的。 （如果你想深入快速学习Kubernetes， 可以报名参加我们组织的为期3天的Kubernetes实战培训 ，一线资深讲师带你从0开始上手Kubernetes。）

灵活的任务调度策略： Mesos 胜出

Mesos 对各种任务的调度策略也要支持的更好。举个例子，如果某一个作业，需要 All or Nothing 的策略，Mesos 是能够实现的，但是 Kubernetes 完全无法支持。所以为的 All or Nothing 的意思是，价格整个作业如果需要运行 10 个任务，这 10 个任务需要能够全部有资源开始执行，否则的话就一个都不执行。

性能： Mesos 胜出

Mesos 的性能应该更好，因为资源调度组件，也就是 Mesos Master 把一部分资源调度的工作甩给 Framework了，承担的调度工作更加简单，从数据来看也是这样，在多年之前 Twitter 自己的 Mesos 集群就能够管理超过 8万个节点，而 Kubernetes 1.3 只能支持 5千个节点。

调度延迟： Kubernetes 胜出

Kubernetes 调度延迟会更好。因为 Mesos 的轮流给 Framework 提供 Offer 机制，导致会浪费很多时间在给不需要资源的 Framework 提供 Offer。