实录分享 | IBM马达：Kubernetes/Swarm on Mesos

4月17日，Mesos爱好者在北京P2联合创业办公社迎来了第四次Mesos User Group约会，下面是来自IBM马达的分享实录。

做者介绍：马达，IBM 高级软件工程师，Kubernetes/Mesos代码贡献者。

很高兴参加此次活动，以前我一直从事分布式计算；从硕士阶段就开始在作分布式资源的调度及优化这一块，当时是基于Globus作跨机群的资源调度。毕业时加入了百度，后来进入了Platform Computing公司；Platform Computing是一家有着20多年分布式经验的公司；2012年Platform Computing被IBM收购，如今作为IBM一个子部门继续从事分布式相关的工做。凭借咱们在分布式方面很是丰富的经验，咱们在与分布式相关的开源项目都有比较多的贡献，此次主要讲与Mesos， Kubernetes，Swarm相关，还有其它团队在作Spark相关的项目。我会介绍一下Kubernetes和Swarm与Mesos的集成；好比说在公司的选型上谈一下我本身的想法，你们能够一块儿交流，若是有一些其余的想法，你们也能够一块儿讨论。

我先简单介绍一下这三个产品，而后讲一讲为何要把Kubernetes和Swarm集成到Mesos上；而后介绍一些集成的细节，后面还有一些遇到的Challenge。最后，咱们已经有一款本身的产品，叫EGO，和Mesos比较像。后续会逐渐将咱们的经验及想法贡献到社区，咱们作的主要是资源的调度，提升云和集群中资源的使用效率。

首先介绍一下三个产品；Kubernetes是Google推出的，参考Google Borg的开源实现，如今支持它的有红帽、惠普、华为等企业。Swarm是Docker下的项目，Swarm的目标是100%兼容Docker API，如今已经达到90%多；有些API在分布式环境中比较难处理，后面会有介绍。Mesos是此次演讲的重点，Mesos由Mesosphere公司来支持，第二大的commiter是Twitter，第三大的社区贡献者是IBM。IBM上个季度贡献了200多代码。Mesos主要是为了将资源抽象出来，尤为是CPU这些资源抽象出来，使整个集群看起来就像一台机器；用户只要关心他使用什么样的资源就能够了，这是Mesos的做用，也就是进行资源的调度和编排，提升整个资源的使用率，减小IO，最终下降开发和运维的成本。

我原来在百度的时候，百度的运维团队很是庞大，研发要给他写一个脚本，也就是上线步骤，告诉他第一步怎么办，第二步怎么办，第三步怎么办，运维人员按照这个脚原本执行。业务上线之后，通知研发检查有没有问题。如今跟原来的同事聊，有了很大的变化，不少东西都有自动化的脚本，包括资源的利用，大概须要什么样的资源，它会自动的支撑脚本。Mesos就是作这件事，把整个资源的运维用机器作起来，减小手动。

说一下为何集成到Mesos上，Kubernetes和Swarm最主要的目标是Container，咱们但愿对资源能够共享，好比说双十一，会有峰值的时候；系统在平时会有一个估值，提供基本的服务资源；剩下的机器作一些线下的分析。Mesos为这样的需求提供了一种解决方案。

“Auto-Scaling”和“不依赖于特殊网络”；这两种个缘由说服力不强：网络本身用脚本就能够作了，Auto-Scaling用脚本也差很少；主要优点仍是资源共享，在DCOS上资源共享相对来讲比较重要。如今大部分的公司还在专一于网络和存储，能够将容器链接进来并能够访问共享数据；可是过一段时间你会发现，网络和存储不是大的问题之后，你们会关心资源的利用率；若是10台机器的资源利用率提升10%，带来的好处并不明显，但若是是1万台机器能提升10%的利用率，那集群至关于多了1000台机，带来的效果仍是很明显的。

这是Kubernetes在Mesos的一个结构图，Kubernetes最左边这个地方就是Kubernetes本身自己的一些Master的东西，其实在Master最主要的是资源调度Scheduler这一块，Scheduler的资源是Mesos Master分出来的，因此在Kubernetes对Mesos来讲只是其中的一个framework，Kubernetes和Spark能够共享资源。Kubernetes提供的CloudProvide不少，它能够跟其余的云厂商能够进行集成。在调度资源里面，Kubernetes还会遵循现有的调度策略。可是有一个问题，就是Scheduler在计算的时候，分配的资源只是基于Mesos给它的东西，好比Mesos分给Scheduler机器A，可是可能机器B上有一个更优的资源，它实际上是拿不到的。

Scheduler拿到资源之后仍是经过Mesos来启动计算节点，Kubernetes的Master至关于Mesos的一个Framework。这个计算节点的executor其实这个作的仍是蛮不错的。在Kubernetes 中提供了一个Kubelet的库用于容器的管理，这个集成项目把Kubernetes和mesos的Executor作了集成，两边作的都是蛮好的。最开始觉得是Slave再去起一个Kubernetes 的 Agent，那样计算节点的开销会很大。如今的解决方案至关因而把Kubernetes集中到Mesos的Executor。Kubernetes On Mesos，本身作了Executor，改了Scheduler，基本上还保持了Kubernetes原有的功能，对原来的支持仍是蛮不错的。

集成的问题，其实从整体架构来看，你们都是提供了集成的方法，但彼此的集成方案很难统一。并且在概念和功能上也有很大的区别，好比说Namespace和Quota，这是Kubernetes本身的功能，这两个彼此的资源都看不到。可是这个集成方案中，他并无映射到Mesos本身的Role，整个Kubernetes映射成一个Role，这个Role能拿到多少Quota，就是Kubernetes 的资源。

另外就是刚才说的关于Optimistic Offer、Revocable resources。所谓资源共享，是Mesos上的一个Framework能够把本身不用的资源借出去，可是当我要的时候，我应该能够把资源抢占回来。并且当资源被抢占的时候须要给出必定的时间进行清理。Optimistic Offer如今会直接把资源抢回来，并且没有一个接口通知相应的做业进行后续的清理工做。好比说我要删某一个进程我应该告诉你怎么删，我要作一些东西。Kubernetes没有对Revocable resources作这些相应的处理。

另外，Mesos本身对Revocable Resources的支持力度也不是特别大。如今支持一种Revocable Resource：当机器分出去的Resources，可是没有用，也能够作Revocable resources。如今和Committer交流，咱们常常提这个功能，他们并无意识到资源的使用率对整个集群有多重要。集成的时候，Unified Container，把镜像下下来去解析。做为Unified Container，它并无提供API, Kubernetes要用Docker的API完成这些工做，若是想把这些引到你的Unified Container，就意味着你的Unified Container要支持Docker的API,这对Mesos来讲是很重要的。Docker的API最大问题是并无一个统一的标准，它的镜像是能够下载下来的执行，可是Docker自己的API没有标准，Mesos的Unified Container要去兼容它的API是一件很繁重的工做。

另外就是Persistent Volume，Mesos本身提供了Persistent Volume，这个做业在机器上重启之后，这个资源所使用的文件会被留下来；若是没有Persistent Volume，则沙箱里的数据都会被删掉，这一块并无跟Kubernetes本身的Persistent Volume集成在一块，Kubernetes本身的Persistent Volume作的事情是把Volume作成一种资源，好比说是1G或者2G，而后能够请求和做用这些资源；其实跟Mesos的功能是从想法上是彻底一致的。但这里有一个效率的问题，Kubernetes本身Persistent Volume可以拿到全局全部的资源，可是若是基于Mesos的话，只能拿到Mesos固定的一些资源，因此这个Kubernetes只能基于不是最优集成拿到最好。其实最主要的你们都有本身的概念和想法，是没有一我的去作两边的集成，你们都认为应该跟随，到底谁应该跟随谁。

Swarm相对来讲还简单一点，Swarm对于资源还好，最开始的时候其实Swarm他会去发一个请求，这个请求仍是本身Mesos的系统，他会本身作一个Schedule，告诉Master。由于Swarm运行Docker UPS，有一个路径，因此这个东西资源分配给Swarm Cluster，这个资源分到Swarm，资源分到这，Swarm会告诉他在哪一台机器上，而后Swarm会连这台机器上的Container。再取那个信息，整个的过程是达到Swarm拿到这个机器之后会告诉Master，Run就基于Mesos本身对Docker的支持。透过这个信息也会告诉你连这个Docker，把这个信息盖了，这个集成会比较简单一点。

Swarm这一块相对来讲作的稍微好一些，它会抽象成一个集群，它跟Mesos相对来讲关系比较好的。可是Swarm自己的功能相对来讲比较少，须要依赖于Docker，才能搭一个大的环境。集成的时候，咱们有类似的这些东西，也有类似的问题，尤为是Docker API，好比说我先推一个，等我Run的时候，若是那个资源一直留在那儿的时候，这个资源一直留着，由于也不知道何时开始，不知道何时把容器起起来，这个CPU有可能闲了两天，仍是用Mesos其余的功能来弥补。后面有Role和Quota，Swarm在很早的时候不支持Role，Swarm提供了基于Mesos的Role的支持。

如今Mesos和Swarm有一个集成，你常常会看到Kubernetes发一个新的版本，Mesos过两天就说我支持这个版本，最明显的是Kubernetes 1.1，Mesos立刻跳出来讲我支持1.1了。而Kubernetes最近发了1.2，可是Mesos却没有动静了。

Swarm最新版本我记不住了，Swarm如今仍是以Docker为主。其实后面Unified Container对它来讲是比较麻烦的一件事情。刚才咱们说了Swarm会连机器，若是你用Unifed Container，最后Swarm就没有办法集成。我我的猜，过一段时间Mesos若是这个集成还再继续往前走，Docker Executor有可能会跟Swarm集成放在一块去，不用Unifed Container。其实Kubernetes、Swarm这些都是依赖于Docker镜像作出来的。这一块如今有压力，如今没有一我的跳出来讲这个事情到底应该怎么办。

Pesistent Volume包括有一些Role，不知道它后续想怎么去作这些新的东西，由于Swarm如今它们的集成也不是特别的安全。

Challenges这部分，对新的东西的集成，其实这种集成如今跟的特别紧。包括像Security是集成的挑战。Mesos告诉你本身想作什么样的Security就去作，你加一个用户或者改一个权限的话，它俩的集成这一块如今其实还在调查之中，本身玩一玩还好。

Multi-Tenant我刚才也说的，该怎么作决定，尤为是多层级的资源调度。好比说有一个部门，这个部门下面有三我的，每一个人用到的资源咱们也是在这里作，其实这种role就是一层，若是是三级部门去作这种资源分配仍是很好作的。集成咱们如今两个在一块儿作，Mesos咱们会推这些资源容器，Kubernetes这一块如今是还在作的一个事情。新的集成这个只能说有新功能找新的解决方案，按案例来作。另外，集成的时候，你们都会用到Kubernetes有本身的UI，这些都是社区的，都是分开的。因此你作Monitoring要本身去作，包括集成的时候，把它的信息全都抓起来观察整个集群的信息，不能单看一个，要把全部的东西全抓住，分析整个系统资源和环境资源，是否是使用率最高的，就是说有没有错误，或者说不是按照小范围来分的。这些都是Mesosphere本身来作的。如今在社区里面其实主要支持这张PPT的上面这三个。

IBM咱们本身在作分布相关的产品，咱们作了Mesos on EGO，在资源调度、分配、共享等方面有很大的优点。咱们在作了Mesos on EGO之后，咱们会有一个统一的资源管理系统提供资源计划，资源抢占等；其实咱们在EGO里面其实已经作出来了。还有资源的分配，咱们原来作企业级的产品，当时最大的客户应该有300多个Role来进行资源的分配和共享。咱们如今作这种Policy，咱们本身的产品跟Mesos集成，另一个也会作一些相关的通用的功能。我主要讲的内容就是这么多。谢谢你们！