剑客
关注科技互联网

IBM 的 Kubernetes on Mesos 探索之路

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

IBM 的 Kubernetes on Mesos 探索之路

我叫马达,名字很好记,挂的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孵化项目里面。

IBM 的 Kubernetes on Mesos 探索之路

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-incubator/kube-mesos-framework/),到Github可以找到相关的资料。

为什么 kube-mesos?

IBM 的 Kubernetes on 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项目的一些功能,有许多问题和经验,有机会可以聊一下。

IBM 的 Kubernetes on Mesos 探索之路

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

IBM 的 Kubernetes on Mesos 探索之路

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。可以看到整个产品的架构从零几年开始做,而且基本验证了至少现在是一个正确的方向。

待解决问题

IBM 的 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去做这样的调度。

IBM 的 Kubernetes on Mesos 探索之路

图中标红的这部分,现在去下这个包,装下来的时候,你会看到,这个东西它改了,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调得非常低,比如调到五百毫秒以内才可以去用一用,社区也有提这个事。

IBM 的 Kubernetes on Mesos 探索之路

现在我们在做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,上面这两个可以通起来的。

IBM 的 Kubernetes on Mesos 探索之路

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

IBM 的 Kubernetes on 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时间表

IBM 的 Kubernetes on 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。谢谢大家!

IBM 的 Kubernetes on Mesos 探索之路

来个招聘: 这里有一份可以兴趣自选的工作……

小数提示:需要PPT的小伙伴请点击阅读原文直接下载:)

IBM 的 Kubernetes on Mesos 探索之路

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址