三分天下，分久必合：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。謝謝你們！