本文是數人云容器三國演義Meetup嘉賓演講實錄第四彈。

記錄正文：

我叫馬達，名字很好記，掛的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-incubator/kube-mesos-framework/)，到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。