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

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

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

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

Kubernetes on Mesos，現(xiàn)在我一般是叫kube-mesos。Kubernetes on Mesos這個(gè)項(xiàng)目最早從2014年開(kāi)始，從Kubernetes剛開(kāi)始的時(shí)候，Mesosphere就投入精力把它們做一個(gè)集成。后來(lái)Mesosphere出了自己的DC/OS，就不再投入資源了。2015年的時(shí)候版本跟得很緊，從0.3一直到0.7十幾個(gè)release，到了2016年最后一個(gè)版本release是0.7.2，到今年的1月份就很少release了。9月，IBM開(kāi)始接手，因?yàn)镮BM整個(gè)產(chǎn)品都是基于這個(gè)Kuberneteson Mesos為基礎(chǔ)的。這時(shí)IBM把它重新定義成一個(gè)孵化器的項(xiàng)目，把它從Kubernetes Github里面拆出來(lái)，放到Kubernetes孵化項(xiàng)目里面。

9月，當(dāng)我們跑Kuberneteson Mesos這個(gè)項(xiàng)目的時(shí)候也是得到了很大的支持，現(xiàn)在的Sponsor是Google的Tim，他主要會(huì)幫我們一起去review Kubernetes on Mesos后面的roadmap，以及什么時(shí)候升級(jí)為Kuberentes的頂級(jí)項(xiàng)目?，F(xiàn)在有一個(gè)叫Champion的角色類(lèi)，Champion這個(gè)角色來(lái)自紅帽的David，他會(huì)和我們做一些daily的review，看一下process和一些BUG。這是我們現(xiàn)在在Github上的一個(gè)ID，所以現(xiàn)在我主要負(fù)責(zé)Kubernetes后面的一些roadmap，也希望大家一起去共享這個(gè)項(xiàng)目，因?yàn)楹竺嬗泻芏喾浅Ｓ幸馑嫉捻?xiàng)目，不僅要改Kuberntes、Mesos，還有我們一些新的想法。下面是Github的地址 (https://github.com/kubernetes... )，到Github可以找到相關(guān)的資料。

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

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

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

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

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

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

從2003年的時(shí)候，IBM就開(kāi)始做這樣相應(yīng)的事情，資源管理是一層，上面的workload pattern是一層。放眼整個(gè)開(kāi)源社區(qū)，我們發(fā)現(xiàn)Kubernetes對(duì)容器的管理這一方面做得更好一點(diǎn)，所以最后選的還是Kuberneteson Mesos整體的架構(gòu)。當(dāng)2006年我們?cè)谧鯠COS類(lèi)似Paas平臺(tái)這樣一個(gè)產(chǎn)品的時(shí)候，最終定出來(lái)的方案就是說(shuō)Kubernetes on Mesos?？梢钥吹秸麄€(gè)產(chǎn)品的架構(gòu)從零幾年開(kāi)始做，而且基本驗(yàn)證了至少現(xiàn)在是一個(gè)正確的方向。

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

這部分還有一個(gè)更大的topic，11月份的KubeCon與Google在討論這個(gè)事情，Google前兩天也有人在做——希望Kubernetes可以提供一種資源管理的功能，無(wú)論是它本身提供還是它提供資源管理這一層，希望Spark可以利用這樣的一個(gè)功能，而不是說(shuō)Spark再去寫(xiě)，希望做這樣的集成。我們也是希望Kubernetes可以更友好的去支持資源管理這一層?；谥暗哪切┙?jīng)驗(yàn)，我們會(huì)在社區(qū)里推動(dòng)它，至少它對(duì)resource manager的支持，不僅僅是對(duì)Mesos的支持。因?yàn)槲抑繦oron work也在做Kubernetes on Yarn，就是說(shuō)這個(gè)Yarn也是資源管理這一層，Yarn、Mesos包括我們內(nèi)部的一些資源管理EGO, 很多都是屬于空層這一層，所以Kubernetes把它定位成一個(gè)container管理的軟件，下面是可以把它完全抽象出來(lái)，讓它更好的接受資源管理這個(gè)東西。

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

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

但是現(xiàn)在Kubernetes并不支持這件事情，它并沒(méi)有去描述哪些作業(yè)是可以跑在上面、哪些是不能跑在上面。因?yàn)榻鑱?lái)這個(gè)resource也會(huì)被高優(yōu)先級(jí)的資源搶占掉，有可能是被殺掉，所以像一些數(shù)據(jù)庫(kù)、一些比較重要的Service是不能跑在上面的，因?yàn)槟銜?huì)跑一些低優(yōu)先級(jí)的作業(yè)，這樣只是說(shuō)有更多的資源可以用。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

希望大家多到社區(qū)貢獻(xiàn)，剛開(kāi)始是有很多討論都可以把它involve進(jìn)來(lái)，因?yàn)榈胶竺骓?xiàng)目比較多的時(shí)候有可能有一些miss。謝謝大家！