實錄分享 | IBM馬達：Kubernetes/Swarm on Mesos

4月17日，Mesos愛好者在北京P2聯合創業辦公社迎來了第四次Mesos User Group約會，下面是來自IBM馬達的分享實錄。

做者介紹：馬達，IBM 高級軟件工程師，Kubernetes/Mesos代碼貢獻者。

很高興參加此次活動，以前我一直從事分佈式計算；從碩士階段就開始在作分佈式資源的調度及優化這一塊，當時是基於Globus作跨機羣的資源調度。畢業時加入了百度，後來進入了Platform Computing公司；Platform Computing是一家有着20多年分佈式經驗的公司；2012年Platform Computing被IBM收購，如今作爲IBM一個子部門繼續從事分佈式相關的工做。憑藉咱們在分佈式方面很是豐富的經驗，咱們在與分佈式相關的開源項目都有比較多的貢獻，此次主要講與Mesos， Kubernetes，Swarm相關，還有其它團隊在作Spark相關的項目。我會介紹一下Kubernetes和Swarm與Mesos的集成；好比說在公司的選型上談一下我本身的想法，你們能夠一塊兒交流，若是有一些其餘的想法，你們也能夠一塊兒討論。

我先簡單介紹一下這三個產品，而後講一講爲何要把Kubernetes和Swarm集成到Mesos上；而後介紹一些集成的細節，後面還有一些遇到的Challenge。最後，咱們已經有一款本身的產品，叫EGO，和Mesos比較像。後續會逐漸將咱們的經驗及想法貢獻到社區，咱們作的主要是資源的調度，提升雲和集羣中資源的使用效率。

首先介紹一下三個產品；Kubernetes是Google推出的，參考Google Borg的開源實現，如今支持它的有紅帽、惠普、華爲等企業。Swarm是Docker下的項目，Swarm的目標是100%兼容Docker API，如今已經達到90%多；有些API在分佈式環境中比較難處理，後面會有介紹。Mesos是此次演講的重點，Mesos由Mesosphere公司來支持，第二大的commiter是Twitter，第三大的社區貢獻者是IBM。IBM上個季度貢獻了200多代碼。Mesos主要是爲了將資源抽象出來，尤爲是CPU這些資源抽象出來，使整個集羣看起來就像一臺機器；用戶只要關心他使用什麼樣的資源就能夠了，這是Mesos的做用，也就是進行資源的調度和編排，提升整個資源的使用率，減小IO，最終下降開發和運維的成本。

我原來在百度的時候，百度的運維團隊很是龐大，研發要給他寫一個腳本，也就是上線步驟，告訴他第一步怎麼辦，第二步怎麼辦，第三步怎麼辦，運維人員按照這個腳原本執行。業務上線之後，通知研發檢查有沒有問題。如今跟原來的同事聊，有了很大的變化，不少東西都有自動化的腳本，包括資源的利用，大概須要什麼樣的資源，它會自動的支撐腳本。Mesos就是作這件事，把整個資源的運維用機器作起來，減小手動。

說一下爲何集成到Mesos上，Kubernetes和Swarm最主要的目標是Container，咱們但願對資源能夠共享，好比說雙十一，會有峯值的時候；系統在平時會有一個估值，提供基本的服務資源；剩下的機器作一些線下的分析。Mesos爲這樣的需求提供了一種解決方案。

「Auto-Scaling」和「不依賴於特殊網絡」；這兩種個緣由說服力不強：網絡本身用腳本就能夠作了，Auto-Scaling用腳本也差很少；主要優點仍是資源共享，在DCOS上資源共享相對來講比較重要。如今大部分的公司還在專一於網絡和存儲，能夠將容器鏈接進來並能夠訪問共享數據；可是過一段時間你會發現，網絡和存儲不是大的問題之後，你們會關心資源的利用率；若是10臺機器的資源利用率提升10%，帶來的好處並不明顯，但若是是1萬臺機器能提升10%的利用率，那集羣至關於多了1000臺機，帶來的效果仍是很明顯的。

這是Kubernetes在Mesos的一個結構圖，Kubernetes最左邊這個地方就是Kubernetes本身自己的一些Master的東西，其實在Master最主要的是資源調度Scheduler這一塊，Scheduler的資源是Mesos Master分出來的，因此在Kubernetes對Mesos來講只是其中的一個framework，Kubernetes和Spark能夠共享資源。Kubernetes提供的CloudProvide不少，它能夠跟其餘的雲廠商能夠進行集成。在調度資源裏面，Kubernetes還會遵循現有的調度策略。可是有一個問題，就是Scheduler在計算的時候，分配的資源只是基於Mesos給它的東西，好比Mesos分給Scheduler機器A，可是可能機器B上有一個更優的資源，它實際上是拿不到的。

Scheduler拿到資源之後仍是經過Mesos來啓動計算節點，Kubernetes的Master至關於Mesos的一個Framework。這個計算節點的executor其實這個作的仍是蠻不錯的。在Kubernetes 中提供了一個Kubelet的庫用於容器的管理，這個集成項目把Kubernetes和mesos的Executor作了集成，兩邊作的都是蠻好的。最開始覺得是Slave再去起一個Kubernetes 的 Agent，那樣計算節點的開銷會很大。如今的解決方案至關因而把Kubernetes集中到Mesos的Executor。Kubernetes On Mesos，本身作了Executor，改了Scheduler，基本上還保持了Kubernetes原有的功能，對原來的支持仍是蠻不錯的。

集成的問題，其實從整體架構來看，你們都是提供了集成的方法，但彼此的集成方案很難統一。並且在概念和功能上也有很大的區別，好比說Namespace和Quota，這是Kubernetes本身的功能，這兩個彼此的資源都看不到。可是這個集成方案中，他並無映射到Mesos本身的Role，整個Kubernetes映射成一個Role，這個Role能拿到多少Quota，就是Kubernetes 的資源。

另外就是剛纔說的關於Optimistic Offer、Revocable resources。所謂資源共享，是Mesos上的一個Framework能夠把本身不用的資源借出去，可是當我要的時候，我應該能夠把資源搶佔回來。並且當資源被搶佔的時候須要給出必定的時間進行清理。Optimistic Offer如今會直接把資源搶回來，並且沒有一個接口通知相應的做業進行後續的清理工做。好比說我要刪某一個進程我應該告訴你怎麼刪，我要作一些東西。Kubernetes沒有對Revocable resources作這些相應的處理。

另外，Mesos本身對Revocable Resources的支持力度也不是特別大。如今支持一種Revocable Resource：當機器分出去的Resources，可是沒有用，也能夠作Revocable resources。如今和Committer交流，咱們常常提這個功能，他們並無意識到資源的使用率對整個集羣有多重要。集成的時候，Unified Container，把鏡像下下來去解析。做爲Unified Container，它並無提供API, Kubernetes要用Docker的API完成這些工做，若是想把這些引到你的Unified Container，就意味着你的Unified Container要支持Docker的API,這對Mesos來講是很重要的。Docker的API最大問題是並無一個統一的標準，它的鏡像是能夠下載下來的執行，可是Docker自己的API沒有標準，Mesos的Unified Container要去兼容它的API是一件很繁重的工做。

另外就是Persistent Volume，Mesos本身提供了Persistent Volume，這個做業在機器上重啓之後，這個資源所使用的文件會被留下來；若是沒有Persistent Volume，則沙箱裏的數據都會被刪掉，這一塊並無跟Kubernetes本身的Persistent Volume集成在一塊，Kubernetes本身的Persistent Volume作的事情是把Volume作成一種資源，好比說是1G或者2G，而後能夠請求和做用這些資源；其實跟Mesos的功能是從想法上是徹底一致的。但這裏有一個效率的問題，Kubernetes本身Persistent Volume可以拿到全局全部的資源，可是若是基於Mesos的話，只能拿到Mesos固定的一些資源，因此這個Kubernetes只能基於不是最優集成拿到最好。其實最主要的你們都有本身的概念和想法，是沒有一我的去作兩邊的集成，你們都認爲應該跟隨，到底誰應該跟隨誰。

Swarm相對來講還簡單一點，Swarm對於資源還好，最開始的時候其實Swarm他會去發一個請求，這個請求仍是本身Mesos的系統，他會本身作一個Schedule，告訴Master。由於Swarm運行Docker UPS，有一個路徑，因此這個東西資源分配給Swarm Cluster，這個資源分到Swarm，資源分到這，Swarm會告訴他在哪一臺機器上，而後Swarm會連這臺機器上的Container。再取那個信息，整個的過程是達到Swarm拿到這個機器之後會告訴Master，Run就基於Mesos本身對Docker的支持。透過這個信息也會告訴你連這個Docker，把這個信息蓋了，這個集成會比較簡單一點。

Swarm這一塊相對來講作的稍微好一些，它會抽象成一個集羣，它跟Mesos相對來講關係比較好的。可是Swarm自己的功能相對來講比較少，須要依賴於Docker，才能搭一個大的環境。集成的時候，咱們有類似的這些東西，也有類似的問題，尤爲是Docker API，好比說我先推一個，等我Run的時候，若是那個資源一直留在那兒的時候，這個資源一直留着，由於也不知道何時開始，不知道何時把容器起起來，這個CPU有可能閒了兩天，仍是用Mesos其餘的功能來彌補。後面有Role和Quota，Swarm在很早的時候不支持Role，Swarm提供了基於Mesos的Role的支持。

如今Mesos和Swarm有一個集成，你常常會看到Kubernetes發一個新的版本，Mesos過兩天就說我支持這個版本，最明顯的是Kubernetes 1.1，Mesos立刻跳出來講我支持1.1了。而Kubernetes最近發了1.2，可是Mesos卻沒有動靜了。

Swarm最新版本我記不住了，Swarm如今仍是以Docker爲主。其實後面Unified Container對它來講是比較麻煩的一件事情。剛纔咱們說了Swarm會連機器，若是你用Unifed Container，最後Swarm就沒有辦法集成。我我的猜，過一段時間Mesos若是這個集成還再繼續往前走，Docker Executor有可能會跟Swarm集成放在一塊去，不用Unifed Container。其實Kubernetes、Swarm這些都是依賴於Docker鏡像作出來的。這一塊如今有壓力，如今沒有一我的跳出來講這個事情到底應該怎麼辦。

Pesistent Volume包括有一些Role，不知道它後續想怎麼去作這些新的東西，由於Swarm如今它們的集成也不是特別的安全。

Challenges這部分，對新的東西的集成，其實這種集成如今跟的特別緊。包括像Security是集成的挑戰。Mesos告訴你本身想作什麼樣的Security就去作，你加一個用戶或者改一個權限的話，它倆的集成這一塊如今其實還在調查之中，本身玩一玩還好。

Multi-Tenant我剛纔也說的，該怎麼作決定，尤爲是多層級的資源調度。好比說有一個部門，這個部門下面有三我的，每一個人用到的資源咱們也是在這裏作，其實這種role就是一層，若是是三級部門去作這種資源分配仍是很好作的。集成咱們如今兩個在一塊兒作，Mesos咱們會推這些資源容器，Kubernetes這一塊如今是還在作的一個事情。新的集成這個只能說有新功能找新的解決方案，按案例來作。另外，集成的時候，你們都會用到Kubernetes有本身的UI，這些都是社區的，都是分開的。因此你作Monitoring要本身去作，包括集成的時候，把它的信息全都抓起來觀察整個集羣的信息，不能單看一個，要把全部的東西全抓住，分析整個系統資源和環境資源，是否是使用率最高的，就是說有沒有錯誤，或者說不是按照小範圍來分的。這些都是Mesosphere本身來作的。如今在社區裏面其實主要支持這張PPT的上面這三個。

IBM咱們本身在作分佈相關的產品，咱們作了Mesos on EGO，在資源調度、分配、共享等方面有很大的優點。咱們在作了Mesos on EGO之後，咱們會有一個統一的資源管理系統提供資源計劃，資源搶佔等；其實咱們在EGO裏面其實已經作出來了。還有資源的分配，咱們原來作企業級的產品，當時最大的客戶應該有300多個Role來進行資源的分配和共享。咱們如今作這種Policy，咱們本身的產品跟Mesos集成，另一個也會作一些相關的通用的功能。我主要講的內容就是這麼多。謝謝你們！