如何進行Kubernetes做為Mesos 的Framework的理論分析

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

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

Kubernetes 只專注容器，而 Mesos 的目的更多的是在可以支持操作系統進程級別的負載。對企業來說把已存在的業務負載放到一個共同管理的環境更為重要。Kubernetes 允許企業進入一個新的容器化業務負載的原生云，而 Mesos 則是已存在的 Windows、Unix 和Linux 環境的橋梁。

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

對于如何用一種可消費的方式打包這些技術使普通企業用戶為不同的工作負載輕松建立自己的容器管理平臺，我們很快會分享更多的信息，請繼續關注!

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

譯者說

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

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

圖 1 Kubernetes on Meos 來源 GitHub

Kubernetes on Mesos 并不是簡單的在 Mesos 平臺上運行 Kubernetes，而是要把 Kubernetes 集成到 Mesos 項目里，并解決相應的問題。如文章中提到的 IBM 正在處理的一些issue，如設法幫助 kube-DNS 與外部的 DNS（#28453）等。

那么 Kubernetes 做為 Mesos 的一個 Framework 是否有意義？可以分析一下在生產實踐中，兩者的結合會有什么優缺點優。

優點：

1. Mesos 提供在生產環境中運行多個 Framework，當生產環境不僅需要運行容器編排 Kubernetes，還需要運行其他的 Framework 時，這種模式可以讓 Kubernetes 和其它 Framework 共享資源，對系統的資源利用率提升有一定幫助。

2. 通過這種模式 Mesos 可以享受 Kubernetes 對微服務的抽象，并實現讓一組容器運行在相同的 slave 節點上。

3. 同時 Mesos 可以根據負載自動擴展 Kubernetes 的 Worker 節點，而不需要手動去安裝。

4. Kubernetes 也可以不再受節點數量的限制可以得到數倍的擴展。

然而站在現在這個時間節點上，這個方案缺點也十分明顯：

1. 上述提到的優點只有在面對超大型數據中心（10W+物理節點）以上才能體現，但是國內能滿足超大集群規模的企業能有幾家?而國內 BAT 這樣的公司又不使用，都會自己直接開發。

2. 開源生態圈不穩定，本身 Docker 的三種 COEs 還處于發展中，功能都在逐步完善，產品迭代的很快。而且三種 COEs 還存在著競爭的關系，目前結果并不明朗。

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

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

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

關于如何進行Kubernetes做為Mesos 的Framework的理論分析就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。