三分天下，分久必合：IBM的Kubernetes on Mesos探索之路

今天是数人云容器三国演义Meetup嘉宾演讲实录第四弹。说完了各家容器技术的实战，那么最后来看容器技术的融合——IBM正在探索的一条道路。

我叫马达，名字很好记，挂的title是IBM软件架构师，但我更喜欢下面这个角色: kube-mesos社区负责人；我在Mesos和Kubernetes两个社区都有不同的贡献。国内我是较早一批进入Mesos社区的，2014年开始通过meetup认识了很多技术圈的朋友，后来由于公司的需要就转到了Kubernetes，目前在team里主要做的是Kubernetes on Mesos。

很多人对Kuberneteson Mesos有疑问，说这两个东西放在一起到底有没有价值。前段时间有人在微信群里问我是不是为了集成而集成，搞一个噱头，大家一起去玩这个事情。这方面我会讲一下，以及Kuberneteson Mesos现在已经有将近一年没有人维护了，所以现在我们接手以后有很多事情要做，包括后面的很多功能要完善。

kube-mesos历史

Kubernetes on Mesos，现在我一般是叫kube-mesos。Kubernetes on Mesos这个项目最早从2014年开始，从Kubernetes刚开始的时候，Mesosphere就投入精力把它们做一个集成。后来Mesosphere出了自己的DC/OS，就不再投入资源了。2015年的时候版本跟得很紧，从0.3一直到0.7十几个release，到了2016年最后一个版本release是0.7.2，到今年的1月份就很少release了。9月，IBM开始接手，因为IBM整个产品都是基于这个Kuberneteson Mesos为基础的。这时IBM把它重新定义成一个孵化器的项目，把它从Kubernetes Github里面拆出来，放到Kubernetes孵化项目里面。

9月，当我们跑Kuberneteson Mesos这个项目的时候也是得到了很大的支持，现在的Sponsor是Google的Tim，他主要会帮我们一起去review Kubernetes on Mesos后面的roadmap，以及什么时候升级为Kuberentes的顶级项目。现在有一个叫Champion的角色类，Champion这个角色来自红帽的David，他会和我们做一些daily的review，看一下process和一些BUG。这是我们现在在Github上的一个ID，所以现在我主要负责Kubernetes后面的一些roadmap，也希望大家一起去共享这个项目，因为后面有很多非常有意思的项目，不仅要改Kuberntes、Mesos，还有我们一些新的想法。下面是Github的地址 (https://github.com/kubernetes... )，到Github可以找到相关的资料。

为什么kube-mesos？

为什么要做这样一个项目，把两个社区或者两个比较复杂的东西放在一起。大家看一个环境的时候，现在讨论最多的是容器，但真正到一个数据中心或者企业环境，你会发现其中会有各种各样的workload，Kubernetes on Mesos只是其中的一部分。在作业管理和应用管理这一层的话，比如跑大数据会希望用Spark；跑管理容器相关的时候，可以跑一些Kubernetes 、Marathon这样的功能。但这时候是分开的，不同的workload使用不同的框架。再往下一层的时候，这些workload，是可以把资源共享、可以把资源重新抽象出来。

这就是Mesos最开始提的事情，把资源重新抽象出来，抽象出一个资源池，有CPU、有memory。这也是为什么Mesos在描述自己的时候，它会说抽象出一个资源池，在Google的Omega文章里面，它也会提把Mesos定义为第二代调度的策略，两级的调度出来scheduling。Omega这个事，Google还没有实现，所以现在也无人提。

真正说容器、说Docker的时候，最早它只是一个运行环境，每一台机器上一个Docker agent，然后把机器提起来，负责一些起停监控等。我们把资源管理用Mesos抽象出来，上层的应用管理可以放Kubernetes，也可以放Marathon、Spark。一些用户已经搭建了环境，底层是Mesos，上面的容器化是跑Kubernetes，大数据跑Spark。Hadoop那些的话，我们当时是在测试Myriad项目的一些功能，有许多问题和经验，有机会可以聊一下。

容器基本都在PaaS这一层，IaaS那一层Openstack搞定所有的事情。Paas这一层抽象出来，就是是Mesos上面加Kubernetes，包括上面真正的运行环境加Docker。各个厂商当你做一个完整的solution，统一用户的管理、统一的界面，都是差不多的。做整个流程时，你不希望用户还去在意下面是跑Mesos还是Kubernetes，于是对外最后就把它抽象成业务的一个逻辑和一个业务的描述。

IBM从1992年的时候开始做自己的产品叫LSF，就是说在九几年的时候像PDS、SGE，早期的HPC, 网络计算基本上都属于这一期的。大家都比较像，workload的管理和资源管理都放在一起了。但等到2003年的时候，资源管理那一层，IBM在做新产品的时候资源管理层又做了一遍，而且是有这样的需求，一些大的银行用户里面LSF和Symphony两个是需要同时跑在一起的，而且由于它们业务上的问题，白天的时候大部分资源给Symphony这个产品，晚上的时候有一部分资源要给LSF，即另外一个产品。

中间资源的切换，如果是原来的话，只能去写脚本，把这个cluster一些agent重新提起来放在那边，但是下面如果把这个资源这层重新抽象出来的话，我们内部产品叫EGO，其实跟Mesos非常像，这也是为什么IBM在Mesos有很大的投入。包括我们这边有很多高级调度策略，像刚才说按时间的调度，包括一些资源的分配和资源的共享。

从2003年的时候，IBM就开始做这样相应的事情，资源管理是一层，上面的workload pattern是一层。放眼整个开源社区，我们发现Kubernetes对容器的管理这一方面做得更好一点，所以最后选的还是Kuberneteson Mesos整体的架构。当2006年我们在做DCOS类似Paas平台这样一个产品的时候，最终定出来的方案就是说Kubernetes on Mesos。可以看到整个产品的架构从零几年开始做，而且基本验证了至少现在是一个正确的方向。

待解决问题

Kuberneteson Mesos现在将近有一年没有再发布新的版本了，目前有很多问题。第一个，Kubernetes on Mesos这个项目到年底、明年年初最主要做这个项目就是要把整个refactor一下，最主要的原因是现在的Kuberneteson Mesos对Kubernetes的代码依赖非常严重。它集成的时候是把Kubernetes里面很多组件拿过来，在外面再包一下，它是代码级别的改造。我在9月份刚开始接受那个项目的时候，经常会有Kubernetes主干的人告诉我，我们这块有interface变了，你要赶紧去看一下，要不然可能就编译不过，问题是它的改动基本都是内部的interface，其实对我外部的像RESTful API这些东西是不需要变的。所以在这块最主要做的是要把它分离出来，跟Mesos、Kubernetes集成的这些interface和这些接口，我们都希望通过它的RESTful API来做。

这部分还有一个更大的topic，11月份的KubeCon与Google在讨论这个事情，Google前两天也有人在做——希望Kubernetes可以提供一种资源管理的功能，无论是它本身提供还是它提供资源管理这一层，希望Spark可以利用这样的一个功能，而不是说Spark再去写，希望做这样的集成。我们也是希望Kubernetes可以更友好的去支持资源管理这一层。基于之前的那些经验，我们会在社区里推动它，至少它对resource manager的支持，不仅仅是对Mesos的支持。因为我知道Horon work也在做Kubernetes on Yarn，就是说这个Yarn也是资源管理这一层，Yarn、Mesos包括我们内部的一些资源管理EGO, 很多都是属于空层这一层，所以Kubernetes把它定位成一个container管理的软件，下面是可以把它完全抽象出来，让它更好的接受资源管理这个东西。

就代码级别来看的话，其实Swarm对资源管理层支持得更好，因为它默认自己是需要有资源管理这一层的，它把自身Swarm和内部这个调度都重新写成了一个resources manager资源管理。虽然它没有Mesos强，但是跟Mesos是一样的，所以它很容易就接到Mesos里面去。但Kubernetes现在是不用做这样的事情，它把整个全都揉到一起，所以这在后续的KuberCon，我们也需要更多人去讨论，是希望它能把这个东西得抽象出来，而不是说我们自己再去搞这样的东西。

revocable resources在Mesos里面基本上是资源的借入借出。现在的revocable resources，Mesos只支持超频（Oversubscription），这个功能现在只是超频这个部分，但现在在跟Mesos的社区讨论的时候，我们希望做这种资源的共享和资源的抢占。所谓资源的共享，举一个例子，我们在跟用户去做大数据和long running service两个同时在跑的一个环境里面的时候，对于大数据的机器是预留下来的，Mesos里面用它的动态预留或者静态预留，应该是这部分的机器留在那儿了，因为这部分机器是相对来说比较好的，无论是网络还是存储。大数据跑起来经常会有一些数据的迁移，所以它的网络经常会被压得比较满，再把一些优先级别比较高的应用放在上面网络性能会比较差一点。但大数据的workload又不是时时的占满，经常会有一些空闲，所以也希望它预留下来的这一部分是可以借出去，借给Kubernetes一部分，Kubernetes在上面可以跑，比如跑一些测试，一些build，就跑这些其实优先级并没有那么高的应用，那么从大数据的资源池借来部分resource基本就变成了revocable resources。

但是现在Kubernetes并不支持这件事情，它并没有去描述哪些作业是可以跑在上面、哪些是不能跑在上面。因为借来这个resource也会被高优先级的资源抢占掉，有可能是被杀掉，所以像一些数据库、一些比较重要的Service是不能跑在上面的，因为你会跑一些低优先级的作业，这样只是说有更多的资源可以用。

当上面去跑两个framework的时候，你跑Kubernetes和Spark，你会发现它俩之间是需要互相访问一些数据的，有的时候是运行结果，有一些是中间的数据。我们希望可以用地址去寻址，但是Kubernetes的DNS基本上在Spark里面又可以跑，所以你这个时候最希望的是什么？Kubernetes的DNS跟Web的DNS可以通了，可以互相访问。这不光是DNS的事情，包括下面Spark的作业，因为我们在做propose的时候，Spark其实跑在Mesos上了，无论你的Spark master是通过Kubernetes把它拉起来还是自己手动提起来，至少作业的那部分是重头，作业是希望它们可以互相访问的，所以除了DNS可以互通，底层的network也是需要互通的。

与Mesos集成这部分是跟resource相关的，因为在Kubernetes里边现在有太多自己的namespace和Quota。Mesos还有一套，有自己的role和 Quota。现在社区里面在做支持一个framework注册多个role，用多个role的身份注册到Mesos上面，还在做层级的role，就像一个树状结构。因为这块有一些需求是这样的，在做部门的时候， Mesos做下层资源管理时，大部分时间你是按部门的层级下来的。现在有很多人在做了，最后就变成部门一下划线，子部门一，然后再下划线，以这种形式做成一个role，但是这种更多的是做成一个tree，而且每个树状结构彼此之间是要再做一层调度的，再做一层DNS的算法调度。

无论如何，现在Mesos还不支持那么多，但是现在Kubernetes自己有一套，Mesos自己也有一套，做起来会比较麻烦，你会发现Mesos给你分配了，有可能Kubernetes限制一下，你就分不出去了；或者说Kubernetes你感觉可以分了，但是你到那边去又调不出来，所以这两个是需要统一的。但统一有一个问题，Kubernetes做这件事情的时候，它并没有认为这些事情应该是需要resourcemanager或者cloud provide参与的，这个事情也是需要在社区propose，它的Quota和namespace需要参考下面的resourcemanager资源分配的那一层。

Kubernetes在做scheduler，其实这只是一个特例的case，特例的case是需要有一些加强的，包括Mesos。Kuberneteson Mesos，Kubernetes本身可以有service affinity，包括它自己可以去选择node selector等等功能，但是这些信息Mesos是不知道的，因为Mesos发offer的时候，它只管自己的事，比如说我有两个framework，可能那个资源换过来以后能达到更好的效果，但Mesos不知道这事，所以Mesos这块本身需要加强，Kubernetes需要哪些resource，Mesos应该知道的。分出来了以后，Kubernetes也有一层的调度，如何来更好的做这样的事情。最终会变成Mesos要两层的调度：第一层，Mesos做一层，然后资源调度尽量的分出，尽量大家都匹配好；第二层，再交给Kubernetes去做这样的调度。

图中标红的这部分，现在去下这个包，装下来的时候，你会看到，这个东西它改了，scheduler它改了，它还有一个executor，这个executor下面还有一个minion进程，然后再去起这两个子进程。而Kubernetes也改了，它用下面Kubernetespackage的包来做，不用那个command了，它重新改了command。唯一没改的就是API和proxy。但是当refactor以后，我们希望这两个地方都不要改了，我们真正release的时候只有一个scheduler去做这个资源的交互。只有executor来做这样的事情，其它的事情还是希望走它原来的逻辑来做。

这其中对Kubernetes本身是有一些变化的，是需要跟Kubernetes去做这样的事情，因为只有单独这个项目想把它做得那么流畅的话，不太现实。最主要的原因是Kubernetes现在自己并没有完全的去接受，并没有完全去把这个东西做成一个插件。虽然它的scheduler已经把它放到plugin里面，但它现在做得也并不是特别好。在后续的工作里面，借着子社区的建设，我们也会逐渐希望Kubernetes把这个底层的资源调度做得更好，而不是像现在这样所有都攒在一起。Kubernetes在资源管理这一层，资源管理像Mesosresource manager这样的一层，它如果两边都做，不见得能做得那么好。

我们现在做Kubernetes、做上层的时候，更在意的是它的功能。Kubernetes在announce一个新版本的时候，1.4去测10万还是几万请求压力时，它强调的一是请求不停，service不停，它并没有强调资源的调度是否OK。那个只是service的一部分，因为如果在上面加一个Spark、加一个其它的大数据上的东西，Mesos也有问题，Mesos短作业做得特不是别好，性能有时候上不来，你需要把scheduler inverval调得非常低，比如调到五百毫秒以内才可以去用一用，社区也有提这个事。

现在我们在做revocable resource时也有问题，比如Kubernetes跟其它的framework去交互，集成的时候Mesos下面走executor，现在所有的Kubernetes都在一起的，你如果去借了资源的话，你有可能revocable resource和regular resource都放在同一个Kubernetes上跑。但是Mesos为了能够完全清理所有的东西，它杀的时候直接把这东西全杀了，把executor下面所有的东西都杀掉了。当去杀这个revocable resource的时候，你会发现下面有可能顺带的把那些你不想杀的东西都杀掉了，把regular resource杀掉了。

现在我还没有最终的解决方案，办法之一是起两个Kubernetes。但是Kubernetes设计的时候，它希望你一个节点去起一个东西，不要起那么多。revocable resource这块到底该如何做大家可以一起讨论一下，因为Mesos有自己的一套策略，Kubernetes也有自己的策略。我们也在跟Mesos社区提这个事情，要提供一个机制去杀task，如果task执行不了，再去杀executor。但是这个项目貌似并没有特别高的量级，我们也在想办法要么去改Mesos、要么去改Kubernetes，让它把这块做得更好。毕竟如果误杀，整个功能就没有特别大的意义了。其实作业上经常会有混合的形式。

现在Kubernetes有这么多namespace，该怎么办？Mesos一直想做multiple role，从去年年底、今年年初design document就已经出来了，但是一直没做。它的功能是把Kubernetes作为一个frameworks，它可以role1、role2、role3这三个role注册到Mesos里面，Mesos里面会根据它自己现有DRF相对三个role来分配资源。往上对应的话,有可能role1就对应namespace1，role2就对应amespace2，role3是amespace3，这样跟Kubernetes就可能对得起来。比如它的Quota是管理文件这些事情，它的资源可以跟Mesos的Quota，上面这两个可以通起来的。

这也是我们一直在想做的事情，Mesos和Kuberentes的统一资源管理，希望它把multiplerole做出来。最后你会发现web interface主要是从Kubernetes进来，比如创建一个interface，Kubernetes里面会有一个interface，下面底层是紧接着Mesos带着一个role，所以所有资源的管理都可以穿得起来。但是现在是变成这样了，Kubernetes是以一个role分到Mesos上面，然后在里面自己再去做。这样其实相当于把资源管理分开了，Kubernetes自己管一层，Mesos自己再管一层，最好还是希望Mesos可以去把整个所有的资源管理都管到一块去。

后面是一些细节，一个是scheduler enhancement，因为一旦引入了两级调度，如果还是跟原来一样其实没有任何意义，像K8S service这些事情现在都做得不是很好。Kuberneteson Mesos里面会有很多像like，像constraint，比较像Marathon的一些概念在里边，这并不是一个很好的事情，Kubernetes本身就应该有Kubernetes自己的东西在里面。另一个像对资源的管理和这些Policy，像它动态预留或者静态预留的一些资源，包括它对Quoto的管理，现在也是希望Kubernetes可以去完全支持，而不是自己再来一套。

最后，这是需要跟Mesos一起去work的，一旦有了Service，一旦有了node selector，、希望Mesos能够知道这件事情，然后在做调度的时候也考虑这件事情，而不是盲目的分，分完了半天不能用，再还回去，因为想用那个节点有可能别人已经用了。并不是所有人都按套路出牌，说没有这个level就不用了，这个事情需要Mesos来统一控制的。这也是为什么希望有一个资源管理层，可以控制所有的resource。

网络这一层，当你去架到大数据架到longrunning framework以后，像DNS、network连接，底层是要把它打通的。否则有很多case无法运行，比如一些Spark的数据要连到K8S里面，它永远是通过K8S ingress resource这些东西往上push。

kube-mesos时间表

这是一个大概的时间表，在10月底或者11月初，希望Kuberneteson Mesos在新的code branch可以release版本，延续它之前的版本叫0.7。这个版本大概会留半年到一年。到2016年底、2017年初的时候，计划把refactor这个事情做完，我们现在最主要的事情避免这个项目对Kubernetes本身代码级别的依赖太强，希望通过interface、API搞定这件事情。到2017年的时候，刚才提到的一些主要的feature，像revocable resource以及前期的资源调度，会把它们加进去。

在2017年一季度应该会有一个0.9的release。在2017年最主要做的事情是production，production不是跑两个测试就是production，IBM有一个基于Kubernetes on Mesos的产品，基于产品也会做system test，做一种longivity test，大概一百台机器跑一个月，所以会以产品的形式来release。当它们都做完了以后，我们才会说Kubernetes on Mesos1.0可以上production。那个时候如果大家有兴趣的话可以去试一下，有很多的公司也想把两个不同的workload、公司内部所有的资源统一在一起，上面运行不同的workload。

希望大家多到社区贡献，刚开始是有很多讨论都可以把它involve进来，因为到后面项目比较多的时候有可能有一些miss。谢谢大家！