如何進(jìn)行Kubernetes做為Mesos 的Framework的理論分析

這篇文章給大家介紹如何進(jìn)行Kubernetes做為Mesos 的Framework的理論分析，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對(duì)大家能有所幫助。

在尋找容器編排平臺(tái)時(shí)，開源社區(qū)提供一些如 Kubernetes、Marathon-Mesos 或 Docker Swarm 等可行的選擇。在很多尋找運(yùn)行在線負(fù)載原生云的用戶中，Kubernetes 非常受歡迎，因?yàn)樗鼉?nèi)置支持一系列有用的特性，包括自動(dòng)化部署，負(fù)載均衡，自動(dòng)擴(kuò)展，滾動(dòng)升級(jí)等等 DevOps 用戶尋找的要素。但同時(shí)，在考慮企業(yè)運(yùn)行環(huán)境的負(fù)載范圍，處理多個(gè)框架間共同關(guān)心的問題時(shí)則需要一種更通用的資源管理器，而 Apache Mesos 則解決了這個(gè)問題。Mesos 是一個(gè)輕量的系統(tǒng)，只有230K行的代碼，而 Kubernetes 則有1.3M+，它專注于提供一種基礎(chǔ)資源抽象層，這樣可以按框架來分配資源，處理基于 task 執(zhí)行能力，同時(shí)處理如主機(jī)維護(hù)模式等管理操作。
在 IBM，我們探索了如何通過將 Kubernetes 作為 Mesos 的一個(gè) Framework 讓 Mesos 和 Kubernetes 一起工作。雖然 Mesos 和內(nèi)置在 Kubernetes 可用資源管理功能有一部分重疊,但依然可以使用這兩個(gè)工具協(xié)同管理。這種模式的一個(gè)好處就是不僅有支持一部分類似大數(shù)據(jù)，Spark 負(fù)載的能力，也能讓其他的分析系統(tǒng)可以受益于 Mesos 支持的細(xì)粒度的資源分配。我們認(rèn)為在運(yùn)行高動(dòng)態(tài)的業(yè)務(wù)負(fù)載時(shí)這將提升資源的使用和性能。
Mesos 因?yàn)槭禽p量的，可以在生產(chǎn)環(huán)境中很容易調(diào)度成千上萬的節(jié)點(diǎn)。另一方面雖然 Kubernetes 在迅速改善的規(guī)模和性能，但仍限于1000個(gè)節(jié)點(diǎn)。可以通過把 Kubernetes 運(yùn)行在 Mesos，可以提供一個(gè)在 Mesos 的基礎(chǔ)上運(yùn)行數(shù)倍的 Kubernetes 節(jié)點(diǎn)的能力。

Kubernetes 只專注容器，而 Mesos 的目的更多的是在可以支持操作系統(tǒng)進(jìn)程級(jí)別的負(fù)載。對(duì)企業(yè)來說把已存在的業(yè)務(wù)負(fù)載放到一個(gè)共同管理的環(huán)境更為重要。Kubernetes 允許企業(yè)進(jìn)入一個(gè)新的容器化業(yè)務(wù)負(fù)載的原生云，而 Mesos 則是已存在的 Windows、Unix 和Linux 環(huán)境的橋梁。

作為探索的一部分，IBM 將率先在把Kubernetes 集成到Mesos 的項(xiàng)目中作出貢獻(xiàn)。這里包括設(shè)法幫助kube-DNS 與外部的DNS（#28453），提高Kubernetes的調(diào)度算法（#31068）,讓 Kubernetes 的命名空間可以和 Mesos（#31069）更好的工作，而且支持 Kubernetes 運(yùn)行在異構(gòu)硬件環(huán)境上（#29901）. 這項(xiàng)工作是額外貢獻(xiàn)在 IBM 正在直接執(zhí)行的 Kubernetes 和 Mesos 項(xiàng)目。

對(duì)于如何用一種可消費(fèi)的方式打包這些技術(shù)使普通企業(yè)用戶為不同的工作負(fù)載輕松建立自己的容器管理平臺(tái)，我們很快會(huì)分享更多的信息，請(qǐng)繼續(xù)關(guān)注!

源文連接：Exploring Kubernetes as a Mesos Framework: Does it make sense?
 

譯者說

Mesos 的定義是用于調(diào)度成百上千個(gè)節(jié)點(diǎn)的超大規(guī)模集群管理平臺(tái)，而Kubernetes 的定義是專門用來管理，部署，調(diào)度容器化應(yīng)用的開源系統(tǒng)。2014年6月 Google 宣布 Kubernetes 開源后，同年7月 Google 官方就宣布了和 Mesosphere 的合作，為用戶提供可以讓 Kubernetes 和其他 Framework（如 Hadoop、Spark、Marathon、Chronos等）共享 Mesos 集群資源的能力。這個(gè)合作可以理解成將 Kubernetes 作為 Framework 整合到 Mesosphere 生態(tài)系統(tǒng)中。從功能上看，Mesos 自身更像是一個(gè) IaaS 層的資源管理工具，用來為上層框架提供共享底層資源的能力，再通過上面運(yùn)行 Framework 實(shí)現(xiàn) PaaS 層的應(yīng)用管理，可以調(diào)度和管理不同的 Framework，而 Kubernetesm 則只是一個(gè)調(diào)度管理容器的 Framework。文章中說 Mesos 只有230K行的代碼，而 Kubernetes 則有 1.3M+。Mesos 的代碼要比 Kubernetes 少，是因?yàn)?Mesos 框架不完整，還需要借助好多其他 “Framework”（比如 Marathon、Aurora、Singularity）才能夠像 Kubernetes 那樣做調(diào)度。兩個(gè)產(chǎn)品各自有優(yōu)勢(shì)，也各自有劣勢(shì)，這個(gè)合作的目的是通過兩者的結(jié)合進(jìn)行互補(bǔ)提供一個(gè)滿足用戶更多需求的平臺(tái)。

雖然這個(gè)項(xiàng)目在 Kubernetes 開源后就已經(jīng)提出來，但兩年多過去了，并沒有在生產(chǎn)實(shí)踐中得到有效的落地推廣，現(xiàn)在這個(gè)項(xiàng)目是 Mesos 社區(qū)主導(dǎo)。Mesos 社區(qū)貢獻(xiàn)代碼的主要是 Mesospher、Twitter、IBM 和 Intel，而 Kubernetes on Mesos 這個(gè)項(xiàng)目現(xiàn)在主要由 IBM 在推進(jìn)，Intel 則在最近表示將繼續(xù)投入資金支持 Mesos 項(xiàng)目。他們認(rèn)為雖然 Kubernetes 獲得了很大的突破，但他們并不認(rèn)為 Mesos 與 Kubernetes 是競(jìng)爭(zhēng)者的關(guān)系，Kubernetes 是直接面向應(yīng)用開發(fā)者，而 Mesos 則是面向超大規(guī)模集群部署，更適合數(shù)據(jù)中心。就像文章中說的，Kubernetes 目前還只能管理1000個(gè)節(jié)點(diǎn)，而通過運(yùn)行在 Mesos 上可以數(shù)倍的擴(kuò)展 Kubernetes 的能力，做一個(gè)更大的資源管理平臺(tái)。Intel 認(rèn)為 Mesos 的目標(biāo)是大型數(shù)據(jù)中心的資源管理和編排，當(dāng)把 Kubernetes 運(yùn)行在 Mesos 管理的數(shù)據(jù)中心上時(shí)也將劃清楚兩者之間的區(qū)別。以下為 Kubernetes 在 Mesos 的一個(gè)結(jié)構(gòu)圖：

圖 1 Kubernetes on Meos 來源 GitHub

Kubernetes on Mesos 并不是簡(jiǎn)單的在 Mesos 平臺(tái)上運(yùn)行 Kubernetes，而是要把 Kubernetes 集成到 Mesos 項(xiàng)目里，并解決相應(yīng)的問題。如文章中提到的 IBM 正在處理的一些issue，如設(shè)法幫助 kube-DNS 與外部的 DNS（#28453）等。

那么 Kubernetes 做為 Mesos 的一個(gè) Framework 是否有意義？可以分析一下在生產(chǎn)實(shí)踐中，兩者的結(jié)合會(huì)有什么優(yōu)缺點(diǎn)優(yōu)。

優(yōu)點(diǎn)：

1. Mesos 提供在生產(chǎn)環(huán)境中運(yùn)行多個(gè) Framework，當(dāng)生產(chǎn)環(huán)境不僅需要運(yùn)行容器編排 Kubernetes，還需要運(yùn)行其他的 Framework 時(shí)，這種模式可以讓 Kubernetes 和其它 Framework 共享資源，對(duì)系統(tǒng)的資源利用率提升有一定幫助。

2. 通過這種模式 Mesos 可以享受 Kubernetes 對(duì)微服務(wù)的抽象，并實(shí)現(xiàn)讓一組容器運(yùn)行在相同的 slave 節(jié)點(diǎn)上。

3. 同時(shí) Mesos 可以根據(jù)負(fù)載自動(dòng)擴(kuò)展 Kubernetes 的 Worker 節(jié)點(diǎn)，而不需要手動(dòng)去安裝。

4. Kubernetes 也可以不再受節(jié)點(diǎn)數(shù)量的限制可以得到數(shù)倍的擴(kuò)展。

然而站在現(xiàn)在這個(gè)時(shí)間節(jié)點(diǎn)上，這個(gè)方案缺點(diǎn)也十分明顯：

1. 上述提到的優(yōu)點(diǎn)只有在面對(duì)超大型數(shù)據(jù)中心（10W+物理節(jié)點(diǎn)）以上才能體現(xiàn)，但是國內(nèi)能滿足超大集群規(guī)模的企業(yè)能有幾家?而國內(nèi) BAT 這樣的公司又不使用，都會(huì)自己直接開發(fā)。

2. 開源生態(tài)圈不穩(wěn)定，本身 Docker 的三種 COEs 還處于發(fā)展中，功能都在逐步完善，產(chǎn)品迭代的很快。而且三種 COEs 還存在著競(jìng)爭(zhēng)的關(guān)系，目前結(jié)果并不明朗。

3. 技術(shù)方案過于復(fù)雜，在生產(chǎn)實(shí)踐中會(huì)比只使用一個(gè)產(chǎn)品更復(fù)雜更重，坑也會(huì)更多。兩個(gè)產(chǎn)品本身就有功能重疊的地方，從某種角度上對(duì)用戶來講，這兩個(gè)還是同類的產(chǎn)品，如果一個(gè)也能有滿足用戶需求，又何必同時(shí)用兩個(gè)搞這么復(fù)雜。而且一般企業(yè)不會(huì)把自己弄這么重，都會(huì)是循序漸進(jìn)的推行一些技術(shù)，否則會(huì)消化不良。復(fù)雜度小，能快速實(shí)踐是企業(yè)在選擇新技術(shù)落地的關(guān)鍵，太復(fù)雜的架構(gòu)一般企業(yè)搞不定，只會(huì)導(dǎo)致實(shí)踐周期變長，會(huì)影響長期的穩(wěn)定性，落地將會(huì)變得更難。雖然這種模式功能更全面，但同時(shí)也增加了落地的難度，而部分企業(yè)在現(xiàn)階段還不需要這多么的功能，選擇單一的產(chǎn)品會(huì)適合。

4.  Mesos 是輕量型，代碼比 Kubernetes 的要少，但兩者的結(jié)合又將增加彼此的重量，這是一個(gè)矛盾的設(shè)定。

5. Mesos 的架構(gòu)與現(xiàn)在熱門的 Openstack 定位也存在部分功能重疊，這樣企業(yè)將更不知道如何選擇落地方案，那么這種方案的選擇度將會(huì)很低。

關(guān)于如何進(jìn)行Kubernetes做為Mesos 的Framework的理論分析就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。