三分天下，分久必合：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，它能够role一、role二、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。谢谢你们！