摘要：今天是數(shù)人云容器三國演義嘉賓演講實錄第四彈。說完了各家容器技術(shù)的實戰(zhàn)，那么最后來看容器技術(shù)的融合正在探索的一條道路。月，開始接手，因為整個產(chǎn)品都是基于這個為基礎(chǔ)的。下面是的地址，到可以找到相關(guān)的資料。但這時候是分開的，不同的使用不同的框架。

今天是數(shù)人云容器三國演義Meetup嘉賓演講實錄第四彈。說完了各家容器技術(shù)的實戰(zhàn)，那么最后來看容器技術(shù)的融合——IBM正在探索的一條道路。

我叫馬達，名字很好記，掛的title是IBM軟件架構(gòu)師，但我更喜歡下面這個角色: kube-mesos社區(qū)負責(zé)人；我在Mesos和Kubernetes兩個社區(qū)都有不同的貢獻。國內(nèi)我是較早一批進入Mesos社區(qū)的，2014年開始通過meetup認識了很多技術(shù)圈的朋友，后來由于公司的需要就轉(zhuǎn)到了Kubernetes，目前在team里主要做的是Kubernetes on Mesos。

很多人對Kuberneteson Mesos有疑問，說這兩個東西放在一起到底有沒有價值。前段時間有人在微信群里問我是不是為了集成而集成，搞一個噱頭，大家一起去玩這個事情。這方面我會講一下，以及Kuberneteson Mesos現(xiàn)在已經(jīng)有將近一年沒有人維護了，所以現(xiàn)在我們接手以后有很多事情要做，包括后面的很多功能要完善。

Kubernetes on Mesos，現(xiàn)在我一般是叫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整個產(chǎn)品都是基于這個Kuberneteson Mesos為基礎(chǔ)的。這時IBM把它重新定義成一個孵化器的項目，把它從Kubernetes Github里面拆出來，放到Kubernetes孵化項目里面。

9月，當(dāng)我們跑Kuberneteson Mesos這個項目的時候也是得到了很大的支持，現(xiàn)在的Sponsor是Google的Tim，他主要會幫我們一起去review Kubernetes on Mesos后面的roadmap，以及什么時候升級為Kuberentes的頂級項目。現(xiàn)在有一個叫Champion的角色類，Champion這個角色來自紅帽的David，他會和我們做一些daily的review，看一下process和一些BUG。這是我們現(xiàn)在在Github上的一個ID，所以現(xiàn)在我主要負責(zé)Kubernetes后面的一些roadmap，也希望大家一起去共享這個項目，因為后面有很多非常有意思的項目，不僅要改Kuberntes、Mesos，還有我們一些新的想法。下面是Github的地址 (https://github.com/kubernetes... )，到Github可以找到相關(guān)的資料。

為什么要做這樣一個項目，把兩個社區(qū)或者兩個比較復(fù)雜的東西放在一起。大家看一個環(huán)境的時候，現(xiàn)在討論最多的是容器，但真正到一個數(shù)據(jù)中心或者企業(yè)環(huán)境，你會發(fā)現(xiàn)其中會有各種各樣的workload，Kubernetes on Mesos只是其中的一部分。在作業(yè)管理和應(yīng)用管理這一層的話，比如跑大數(shù)據(jù)會希望用Spark；跑管理容器相關(guān)的時候，可以跑一些Kubernetes 、Marathon這樣的功能。但這時候是分開的，不同的workload使用不同的框架。再往下一層的時候，這些workload，是可以把資源共享、可以把資源重新抽象出來。

這就是Mesos最開始提的事情，把資源重新抽象出來，抽象出一個資源池，有CPU、有memory。這也是為什么Mesos在描述自己的時候，它會說抽象出一個資源池，在Google的Omega文章里面，它也會提把Mesos定義為第二代調(diào)度的策略，兩級的調(diào)度出來scheduling。Omega這個事，Google還沒有實現(xiàn)，所以現(xiàn)在也無人提。

真正說容器、說Docker的時候，最早它只是一個運行環(huán)境，每一臺機器上一個Docker agent，然后把機器提起來，負責(zé)一些起停監(jiān)控等。我們把資源管理用Mesos抽象出來，上層的應(yīng)用管理可以放Kubernetes，也可以放Marathon、Spark。一些用戶已經(jīng)搭建了環(huán)境，底層是Mesos，上面的容器化是跑Kubernetes，大數(shù)據(jù)跑Spark。Hadoop那些的話，我們當(dāng)時是在測試Myriad項目的一些功能，有許多問題和經(jīng)驗，有機會可以聊一下。

容器基本都在PaaS這一層，IaaS那一層Openstack搞定所有的事情。Paas這一層抽象出來，就是是Mesos上面加Kubernetes，包括上面真正的運行環(huán)境加Docker。各個廠商當(dāng)你做一個完整的solution，統(tǒng)一用戶的管理、統(tǒng)一的界面，都是差不多的。做整個流程時，你不希望用戶還去在意下面是跑Mesos還是Kubernetes，于是對外最后就把它抽象成業(yè)務(wù)的一個邏輯和一個業(yè)務(wù)的描述。

IBM從1992年的時候開始做自己的產(chǎn)品叫LSF，就是說在九幾年的時候像PDS、SGE，早期的HPC, 網(wǎng)絡(luò)計算基本上都屬于這一期的。大家都比較像，workload的管理和資源管理都放在一起了。但等到2003年的時候，資源管理那一層，IBM在做新產(chǎn)品的時候資源管理層又做了一遍，而且是有這樣的需求，一些大的銀行用戶里面LSF和Symphony兩個是需要同時跑在一起的，而且由于它們業(yè)務(wù)上的問題，白天的時候大部分資源給Symphony這個產(chǎn)品，晚上的時候有一部分資源要給LSF，即另外一個產(chǎn)品。

中間資源的切換，如果是原來的話，只能去寫腳本，把這個cluster一些agent重新提起來放在那邊，但是下面如果把這個資源這層重新抽象出來的話，我們內(nèi)部產(chǎn)品叫EGO，其實跟Mesos非常像，這也是為什么IBM在Mesos有很大的投入。包括我們這邊有很多高級調(diào)度策略，像剛才說按時間的調(diào)度，包括一些資源的分配和資源的共享。

從2003年的時候，IBM就開始做這樣相應(yīng)的事情，資源管理是一層，上面的workload pattern是一層。放眼整個開源社區(qū)，我們發(fā)現(xiàn)Kubernetes對容器的管理這一方面做得更好一點，所以最后選的還是Kuberneteson Mesos整體的架構(gòu)。當(dāng)2006年我們在做DCOS類似Paas平臺這樣一個產(chǎn)品的時候，最終定出來的方案就是說Kubernetes on Mesos。可以看到整個產(chǎn)品的架構(gòu)從零幾年開始做，而且基本驗證了至少現(xiàn)在是一個正確的方向。

Kuberneteson Mesos現(xiàn)在將近有一年沒有再發(fā)布新的版本了，目前有很多問題。第一個，Kubernetes on Mesos這個項目到年底、明年年初最主要做這個項目就是要把整個refactor一下，最主要的原因是現(xiàn)在的Kuberneteson Mesos對Kubernetes的代碼依賴非常嚴(yán)重。它集成的時候是把Kubernetes里面很多組件拿過來，在外面再包一下，它是代碼級別的改造。我在9月份剛開始接受那個項目的時候，經(jīng)常會有Kubernetes主干的人告訴我，我們這塊有interface變了，你要趕緊去看一下，要不然可能就編譯不過，問題是它的改動基本都是內(nèi)部的interface，其實對我外部的像RESTful API這些東西是不需要變的。所以在這塊最主要做的是要把它分離出來，跟Mesos、Kubernetes集成的這些interface和這些接口，我們都希望通過它的RESTful API來做。

這部分還有一個更大的topic，11月份的KubeCon與Google在討論這個事情，Google前兩天也有人在做——希望Kubernetes可以提供一種資源管理的功能，無論是它本身提供還是它提供資源管理這一層，希望Spark可以利用這樣的一個功能，而不是說Spark再去寫，希望做這樣的集成。我們也是希望Kubernetes可以更友好的去支持資源管理這一層。基于之前的那些經(jīng)驗，我們會在社區(qū)里推動它，至少它對resource manager的支持，不僅僅是對Mesos的支持。因為我知道Horon work也在做Kubernetes on Yarn，就是說這個Yarn也是資源管理這一層，Yarn、Mesos包括我們內(nèi)部的一些資源管理EGO, 很多都是屬于空層這一層，所以Kubernetes把它定位成一個container管理的軟件，下面是可以把它完全抽象出來，讓它更好的接受資源管理這個東西。

就代碼級別來看的話，其實Swarm對資源管理層支持得更好，因為它默認自己是需要有資源管理這一層的，它把自身Swarm和內(nèi)部這個調(diào)度都重新寫成了一個resources manager資源管理。雖然它沒有Mesos強，但是跟Mesos是一樣的，所以它很容易就接到Mesos里面去。但Kubernetes現(xiàn)在是不用做這樣的事情，它把整個全都揉到一起，所以這在后續(xù)的KuberCon，我們也需要更多人去討論，是希望它能把這個東西得抽象出來，而不是說我們自己再去搞這樣的東西。

revocable resources在Mesos里面基本上是資源的借入借出。現(xiàn)在的revocable resources，Mesos只支持超頻（Oversubscription），這個功能現(xiàn)在只是超頻這個部分，但現(xiàn)在在跟Mesos的社區(qū)討論的時候，我們希望做這種資源的共享和資源的搶占。所謂資源的共享，舉一個例子，我們在跟用戶去做大數(shù)據(jù)和long running service兩個同時在跑的一個環(huán)境里面的時候，對于大數(shù)據(jù)的機器是預(yù)留下來的，Mesos里面用它的動態(tài)預(yù)留或者靜態(tài)預(yù)留，應(yīng)該是這部分的機器留在那兒了，因為這部分機器是相對來說比較好的，無論是網(wǎng)絡(luò)還是存儲。大數(shù)據(jù)跑起來經(jīng)常會有一些數(shù)據(jù)的遷移，所以它的網(wǎng)絡(luò)經(jīng)常會被壓得比較滿，再把一些優(yōu)先級別比較高的應(yīng)用放在上面網(wǎng)絡(luò)性能會比較差一點。但大數(shù)據(jù)的workload又不是時時的占滿，經(jīng)常會有一些空閑，所以也希望它預(yù)留下來的這一部分是可以借出去，借給Kubernetes一部分，Kubernetes在上面可以跑，比如跑一些測試，一些build，就跑這些其實優(yōu)先級并沒有那么高的應(yīng)用，那么從大數(shù)據(jù)的資源池借來部分resource基本就變成了revocable resources。

但是現(xiàn)在Kubernetes并不支持這件事情，它并沒有去描述哪些作業(yè)是可以跑在上面、哪些是不能跑在上面。因為借來這個resource也會被高優(yōu)先級的資源搶占掉，有可能是被殺掉，所以像一些數(shù)據(jù)庫、一些比較重要的Service是不能跑在上面的，因為你會跑一些低優(yōu)先級的作業(yè)，這樣只是說有更多的資源可以用。

當(dāng)上面去跑兩個framework的時候，你跑Kubernetes和Spark，你會發(fā)現(xiàn)它倆之間是需要互相訪問一些數(shù)據(jù)的，有的時候是運行結(jié)果，有一些是中間的數(shù)據(jù)。我們希望可以用地址去尋址，但是Kubernetes的DNS基本上在Spark里面又可以跑，所以你這個時候最希望的是什么？Kubernetes的DNS跟Web的DNS可以通了，可以互相訪問。這不光是DNS的事情，包括下面Spark的作業(yè)，因為我們在做propose的時候，Spark其實跑在Mesos上了，無論你的Spark master是通過Kubernetes把它拉起來還是自己手動提起來，至少作業(yè)的那部分是重頭，作業(yè)是希望它們可以互相訪問的，所以除了DNS可以互通，底層的network也是需要互通的。

與Mesos集成這部分是跟resource相關(guān)的，因為在Kubernetes里邊現(xiàn)在有太多自己的namespace和Quota。Mesos還有一套，有自己的role和 Quota。現(xiàn)在社區(qū)里面在做支持一個framework注冊多個role，用多個role的身份注冊到Mesos上面，還在做層級的role，就像一個樹狀結(jié)構(gòu)。因為這塊有一些需求是這樣的，在做部門的時候， Mesos做下層資源管理時，大部分時間你是按部門的層級下來的。現(xiàn)在有很多人在做了，最后就變成部門一下劃線，子部門一，然后再下劃線，以這種形式做成一個role，但是這種更多的是做成一個tree，而且每個樹狀結(jié)構(gòu)彼此之間是要再做一層調(diào)度的，再做一層DNS的算法調(diào)度。

無論如何，現(xiàn)在Mesos還不支持那么多，但是現(xiàn)在Kubernetes自己有一套，Mesos自己也有一套，做起來會比較麻煩，你會發(fā)現(xiàn)Mesos給你分配了，有可能Kubernetes限制一下，你就分不出去了；或者說Kubernetes你感覺可以分了，但是你到那邊去又調(diào)不出來，所以這兩個是需要統(tǒng)一的。但統(tǒng)一有一個問題，Kubernetes做這件事情的時候，它并沒有認為這些事情應(yīng)該是需要resourcemanager或者cloud provide參與的，這個事情也是需要在社區(qū)propose，它的Quota和namespace需要參考下面的resourcemanager資源分配的那一層。

Kubernetes在做scheduler，其實這只是一個特例的case，特例的case是需要有一些加強的，包括Mesos。Kuberneteson Mesos，Kubernetes本身可以有service affinity，包括它自己可以去選擇node selector等等功能，但是這些信息Mesos是不知道的，因為Mesos發(fā)offer的時候，它只管自己的事，比如說我有兩個framework，可能那個資源換過來以后能達到更好的效果，但Mesos不知道這事，所以Mesos這塊本身需要加強，Kubernetes需要哪些resource，Mesos應(yīng)該知道的。分出來了以后，Kubernetes也有一層的調(diào)度，如何來更好的做這樣的事情。最終會變成Mesos要兩層的調(diào)度：第一層，Mesos做一層，然后資源調(diào)度盡量的分出，盡量大家都匹配好；第二層，再交給Kubernetes去做這樣的調(diào)度。

圖中標(biāo)紅的這部分，現(xiàn)在去下這個包，裝下來的時候，你會看到，這個東西它改了，scheduler它改了，它還有一個executor，這個executor下面還有一個minion進程，然后再去起這兩個子進程。而Kubernetes也改了，它用下面Kubernetespackage的包來做，不用那個command了，它重新改了command。唯一沒改的就是API和proxy。但是當(dāng)refactor以后，我們希望這兩個地方都不要改了，我們真正release的時候只有一個scheduler去做這個資源的交互。只有executor來做這樣的事情，其它的事情還是希望走它原來的邏輯來做。

這其中對Kubernetes本身是有一些變化的，是需要跟Kubernetes去做這樣的事情，因為只有多帶帶這個項目想把它做得那么流暢的話，不太現(xiàn)實。最主要的原因是Kubernetes現(xiàn)在自己并沒有完全的去接受，并沒有完全去把這個東西做成一個插件。雖然它的scheduler已經(jīng)把它放到plugin里面，但它現(xiàn)在做得也并不是特別好。在后續(xù)的工作里面，借著子社區(qū)的建設(shè)，我們也會逐漸希望Kubernetes把這個底層的資源調(diào)度做得更好，而不是像現(xiàn)在這樣所有都攢在一起。Kubernetes在資源管理這一層，資源管理像Mesosresource manager這樣的一層，它如果兩邊都做，不見得能做得那么好。

我們現(xiàn)在做Kubernetes、做上層的時候，更在意的是它的功能。Kubernetes在announce一個新版本的時候，1.4去測10萬還是幾萬請求壓力時，它強調(diào)的一是請求不停，service不停，它并沒有強調(diào)資源的調(diào)度是否OK。那個只是service的一部分，因為如果在上面加一個Spark、加一個其它的大數(shù)據(jù)上的東西，Mesos也有問題，Mesos短作業(yè)做得特不是別好，性能有時候上不來，你需要把scheduler inverval調(diào)得非常低，比如調(diào)到五百毫秒以內(nèi)才可以去用一用，社區(qū)也有提這個事。

現(xiàn)在我們在做revocable resource時也有問題，比如Kubernetes跟其它的framework去交互，集成的時候Mesos下面走executor，現(xiàn)在所有的Kubernetes都在一起的，你如果去借了資源的話，你有可能revocable resource和regular resource都放在同一個Kubernetes上跑。但是Mesos為了能夠完全清理所有的東西，它殺的時候直接把這東西全殺了，把executor下面所有的東西都殺掉了。當(dāng)去殺這個revocable resource的時候，你會發(fā)現(xiàn)下面有可能順帶的把那些你不想殺的東西都殺掉了，把regular resource殺掉了。

現(xiàn)在我還沒有最終的解決方案，辦法之一是起兩個Kubernetes。但是Kubernetes設(shè)計的時候，它希望你一個節(jié)點去起一個東西，不要起那么多。revocable resource這塊到底該如何做大家可以一起討論一下，因為Mesos有自己的一套策略，Kubernetes也有自己的策略。我們也在跟Mesos社區(qū)提這個事情，要提供一個機制去殺task，如果task執(zhí)行不了，再去殺executor。但是這個項目貌似并沒有特別高的量級，我們也在想辦法要么去改Mesos、要么去改Kubernetes，讓它把這塊做得更好。畢竟如果誤殺，整個功能就沒有特別大的意義了。其實作業(yè)上經(jīng)常會有混合的形式。

現(xiàn)在Kubernetes有這么多namespace，該怎么辦？Mesos一直想做multiple role，從去年年底、今年年初design document就已經(jīng)出來了，但是一直沒做。它的功能是把Kubernetes作為一個frameworks，它可以role1、role2、role3這三個role注冊到Mesos里面，Mesos里面會根據(jù)它自己現(xiàn)有DRF相對三個role來分配資源。往上對應(yīng)的話,有可能role1就對應(yīng)namespace1，role2就對應(yīng)amespace2，role3是amespace3，這樣跟Kubernetes就可能對得起來。比如它的Quota是管理文件這些事情，它的資源可以跟Mesos的Quota，上面這兩個可以通起來的。

這也是我們一直在想做的事情，Mesos和Kuberentes的統(tǒng)一資源管理，希望它把multiplerole做出來。最后你會發(fā)現(xiàn)web interface主要是從Kubernetes進來，比如創(chuàng)建一個interface，Kubernetes里面會有一個interface，下面底層是緊接著Mesos帶著一個role，所以所有資源的管理都可以穿得起來。但是現(xiàn)在是變成這樣了，Kubernetes是以一個role分到Mesos上面，然后在里面自己再去做。這樣其實相當(dāng)于把資源管理分開了，Kubernetes自己管一層，Mesos自己再管一層，最好還是希望Mesos可以去把整個所有的資源管理都管到一塊去。

后面是一些細節(jié)，一個是scheduler enhancement，因為一旦引入了兩級調(diào)度，如果還是跟原來一樣其實沒有任何意義，像K8S service這些事情現(xiàn)在都做得不是很好。Kuberneteson Mesos里面會有很多像like，像constraint，比較像Marathon的一些概念在里邊，這并不是一個很好的事情，Kubernetes本身就應(yīng)該有Kubernetes自己的東西在里面。另一個像對資源的管理和這些Policy，像它動態(tài)預(yù)留或者靜態(tài)預(yù)留的一些資源，包括它對Quoto的管理，現(xiàn)在也是希望Kubernetes可以去完全支持，而不是自己再來一套。

最后，這是需要跟Mesos一起去work的，一旦有了Service，一旦有了node selector，、希望Mesos能夠知道這件事情，然后在做調(diào)度的時候也考慮這件事情，而不是盲目的分，分完了半天不能用，再還回去，因為想用那個節(jié)點有可能別人已經(jīng)用了。并不是所有人都按套路出牌，說沒有這個level就不用了，這個事情需要Mesos來統(tǒng)一控制的。這也是為什么希望有一個資源管理層，可以控制所有的resource。

網(wǎng)絡(luò)這一層，當(dāng)你去架到大數(shù)據(jù)架到longrunning framework以后，像DNS、network連接，底層是要把它打通的。否則有很多case無法運行，比如一些Spark的數(shù)據(jù)要連到K8S里面，它永遠是通過K8S ingress resource這些東西往上push。

這是一個大概的時間表，在10月底或者11月初，希望Kuberneteson Mesos在新的code branch可以release版本，延續(xù)它之前的版本叫0.7。這個版本大概會留半年到一年。到2016年底、2017年初的時候，計劃把refactor這個事情做完，我們現(xiàn)在最主要的事情避免這個項目對Kubernetes本身代碼級別的依賴太強，希望通過interface、API搞定這件事情。到2017年的時候，剛才提到的一些主要的feature，像revocable resource以及前期的資源調(diào)度，會把它們加進去。

在2017年一季度應(yīng)該會有一個0.9的release。在2017年最主要做的事情是production，production不是跑兩個測試就是production，IBM有一個基于Kubernetes on Mesos的產(chǎn)品，基于產(chǎn)品也會做system test，做一種longivity test，大概一百臺機器跑一個月，所以會以產(chǎn)品的形式來release。當(dāng)它們都做完了以后，我們才會說Kubernetes on Mesos1.0可以上production。那個時候如果大家有興趣的話可以去試一下，有很多的公司也想把兩個不同的workload、公司內(nèi)部所有的資源統(tǒng)一在一起，上面運行不同的workload。

希望大家多到社區(qū)貢獻，剛開始是有很多討論都可以把它involve進來，因為到后面項目比較多的時候有可能有一些miss。謝謝大家！