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

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

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

很多人對Kuberneteson Mesos有疑問，說這兩個東西放在一起到底有沒有價值。前段時間有人在微信群里問我是不是為了集成而集成，搞一個噱頭，大家一起去玩這個事情。這方面我會講一下，以及Kuberneteson 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可以找到相關的資料。

為什么要做這樣一個項目，把兩個社區或者兩個比較復雜的東西放在一起。大家看一個環境的時候，現在討論最多的是容器，但真正到一個數據中心或者企業環境，你會發現其中會有各種各樣的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。

這是一個大概的時間表，在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。謝謝大家！