Kubernetes和Mesos有啥區別，我該使用哪個好?

01-08

Mesos和Kubernetes使用哪個好，關鍵還是要看業務需求，當然是適合業務需求的最好。

兩者參數都都挺多的，針對於容器管理，兩者也都挺靈活，一般都可以滿足，不過學習成本也會相對提高。
兩者對比，有點類似搭積木，Mesos是零散的積木，你需要自己組裝實現自己的業務模型，Kubernetes就是組裝好的積木，你直接拿來用就好了。
Mesos自身定義為一個分散式內核，也就是最核心的資源管理它幫你實現了，如果自己實現業務調度，那麼就需要公司有一定的開發能力，當然了，一般的需求使用Mesos的框架Marathon和Aurora等也能滿足了。
兩者發展的側重點不同，Mesos更側重底層資源的管理，Kubernetes側重業務層的調度，容器服務編排，服務發現等。還有現在Kubernetes也可以運行在Mesos上，這樣你也可以選擇兩者結合。
現在在國內，Kubernetes感覺更火些，個人覺得這可能跟容器的爆發有關，並且有Google公司的光環。

從個人角度看，Mesos相比Kubernetes發展的時間更久，總體情況更成熟，在生產環境有更多的使用經驗，暫且不論國外Twitter，Apple，Airbnb，Uber等如何使用Mesos，僅以國內我所了解的情況，從https://github.com/apache/mesos/blob/master/docs/powered-by-mesos.md

找出使用Mesos的國內公司有：

小米

噹噹

豆瓣

去哪兒

攜程

唯品會

知乎

新浪微博

愛奇藝

七牛

UCloud

唯品會

bilibili

中國聯通

中國移動

中國電信

華為

數人云

...

中大型公司會更傾向於使用Mesos，因為本身公司有一定的開發能力，Mesos提供了良好的API而且有非常多成熟的Framework跑在Mesos上可以作為參考 dharmeshkakadia/awesome-mesos

當然不是指創業公司Mesos就用不來了，Mesos + Marathon/Aurora正常情況可以滿足絕大部分需求，只需要寫JSON或者DSL定義好service/application就好。只有一些特殊情況才確實需要寫自己的Framework

有很多人寫代碼卻從來自己不用，k8s顯然就是這一種類型，Google離職出來到其他公司的人不建議用，Google內部更不會把Borg替換成k8s。k8s在生產環境顯然需要更多時間來驗證。從https://twitter.com/jbedahttps://twitter.com/brendandburnshttps://twitter.com/cmcluck 等大佬從kubernetes離職某種程度上也反應了kubernetes在Google內部的情況。當然公司大了有人員流動也很正常。

mesos

開源的分散式資源管理框架，它被稱為是分散式系統的內核，可以將不同的物理資源整合在一個邏輯資源層面上。當擁有很多的物理資源並想構建一個巨大的資源池的時候，Mesos只最適用的。可以看出 mesos 解決問題的核心是圍繞物理資源層，上面跑什麼，怎麼跑其時並不關注。

k8s

開源的自動化容器操作的平台，操作包括部署，調度和節點集群間擴展等。可以看出 k8s 解決問題的核心是圍繞著容器來做的。

這樣看來兩個系統根本就不在一個維度。更談不上什麼可比性。也可以說明為什麼mesos圈裡，有人研究在 mesos 系統上發布 k8s 作為 mesos 的調度器解決方案。那麼為什麼這麼多人都要用這兩種系統進行比較呢。那是因為單獨的 mesos 本身是無法獨立進行使用的，通常需要使用任務調度器來使用，比如現在流行的 marathon。又因為 marathon 提供了容器任務的管理能力，所以很容易讓不熟悉的人誤認為 mesos 和 k8s 是一類系統。

如果大家都是基於容器要搭建一套解決方案的話，那麼 mesos + 調度器和 k8s 都可以在考慮範圍內。個人思考如下：

1、從業務類型

k8s 幾乎支持了所有的容器業務類型，包含長期伺服型（long-running）、批處理型（batch）、節點後台支撐型（node-daemon）和有狀態應用型（stateful application）；

mesos 這邊設計思路就完全不同，它實際上將這個問題丟給不同的調度器來完成，不同的任務類型需要使用不同的調度器，比如上面提到的 marathon 就是長期伺服型（long-running）。

2、從穩定性而言

k8s 從代碼提交結果來看和 docker 一樣，選擇的是快速迭代來完成自身的進化，這樣隨之帶來的問題就是可能會犧牲一些穩定性。

mesos 的迭代周期相對比較慢，這樣帶來了更大的穩定性。而各調度器迭代速度並不一致，有快有慢，需要特定去看，但如果就 marathon 而言，還是相當穩定的。

3、從功能上

k8s 因為推出的比較晚，並吸納量大量google和其他產品經驗，所以從整體設計上相對比較完整，比如網路層推出了自己的整合方案。(雖然不好用)

mesos 系統的設計思路則定義了任務調度和功能上整體依賴於調度器的設計。所以可以把 mesos 看成一個大樂高底層的基礎板。

最終選擇k8s 也好，選擇 mesos 也好，都不是誰對誰錯，根據自身情況選擇一個最適合自己的工具解決自己的問題才是根本。

Mesos只負責管資源，而Kubernetes抽象出新的容器組合模型並且對其編排管理。

兩者的差別根本不是一個level的，前者只負責資源（動態運行時，某機器有額外的資源了，通知master，來！），後者是更高一級的抽象（把容器自由組合提供服務這事兒搞定了，從而微服務，serverless等才真正的優雅地在開發和運維之間不吵架地被實現），而且kubernetes把以前運維的很多很難搞的東西都變得容易了。

如果你知道OpenStack的話，那麼Kubernetes是把OpenStack裡面的VM換成了容器，但是實現地更漂亮，更精簡，更抽象和本質化，用起來也更容易。

誠如其他答主所言，Apache Mesos 和 Kubernetes 都是優秀的開源框架，都支持大規模集群管理（當然開源 Kubernetes 目前還局限於數千，萬級節點還需要定製化，而 Apache Mesos 可以輕量級地調度萬級節點），在國內都有不少成熟應用。如網易雲、華為都部署了大規模 Kubernetes 集群，愛奇藝、去哪兒、攜程、噹噹等都選擇了 Mesos。

一般說來，如果只是用於容器集群管理，Kubernetes 更加合適，如果定製需求比較多，或者要搭建大數據平台，架構相對松耦合的 Mesos 顯然更加合適。當然，用 Mesos + Kubernetes 做容器編排也是一種可行的技術方案。需要注意，Mesos 和 Kubernetes 二者都需要團隊有很強的技術實力。

從軟體設計初衷來看，Kubernetes 希望成為容器管理領域的領導者，而 AWS、Azure 加入 CNCF、Docker 官方表態原生支持 Kubernetes ，說明 Kubernetes 憑藉源自 Google 的優秀設計，在容器領域的地位已經不可動搖，社區和生態越來越繁榮。

an open-source system for automating deployment, scaling, and management of containerized applications.

Mesos 的目標則是資源共享，可以讓企業把已經存在的業務負載，比如 Hadoop、Spark，放到一個共同管理的環境。

define a minimal interface that enables efficient resource sharing across frameworks, and otherwise push control of task scheduling and execution to the frameworks

至於要不要容器化，就要看對微服務、DevOps 的需求了。如何選擇容器化技術棧，網易雲架構師做了一個比較系統的梳理。

千節點集群，少定製：使用開源 Kubernetes （細粒度設計，契合微服務思想）
萬節點集群，多定製：使用 Mesos + Marathon （雙層調度好犀利）
萬節點集群，IT 能力強：深度定製 Kubernetes （如網易雲）
萬節點集群，IT 能力強：深入掌握使用 DC/OS （DC/OS 在最基礎的 Marathon 和 Mesos 之上添加了很多的組件）
大數據集群：Spark on Mesos （建議只基於容器部署計算部分，數據部分另行部署）

詳情可以看這篇文章：容器平台選型的十大模式：Docker、DC/OS、K8S 誰與當先？

利益相關：網易雲出於標準化和DevOps的目的，採用 Kubernetes + Docker 提供容器雲服務，並參與 Kubernetes 社區代碼貢獻工作。

mesos的定位是資源管理，一般應用於大規模集群；k8s適用於雲計算市場，比較接近市場層面。

我覺得 Mesos 出現的比較早，也比較成熟。但k8s也慢慢成熟了起來，現在使用k8s的公司越來越多。jd已經在k8s上跑15W+容器了。

K8S最近比較火，源於社區的活躍，真正實踐用的怎麼樣還需要時間的認證，目前以K8S為技術棧的創業公司真不少；以Mesos為技術棧的好像一直只有一家數人云，記得他們之前做過一個百萬壓測的實驗，底層用的就是Mesos，前面也看別人提到了Mesos在支持大規模集群上還是很有優勢的，像蘋果、Facebook以及國內的小米，愛奇藝用的都是Mesos.具體用哪個技術還需要更多的調研，多對比一下，明確使用場景和解決方案，不明白的可以去Dockone社區翻翻一些大公司的實踐，寫的還是挺不錯的，應該有幫助

Mesos 和K8s的側重點是不同的。Mesos的兩級調度，資源調度關注的是自身純粹的資源情況，任務調度則需要自己去實現。K8S是更加偏向於用戶，從服務的角度出發，去進行資源編排。打個比方，就像做蛋糕，Mesos關注於怎麼作出更好的奶油、巧克力等原料，K8S關注怎麼做出一個用戶喜歡的蛋糕

自己公司技術團隊能hold住的都可以。

比如說定製特殊需求和出了問題自己定位加修復，如果hold不住還是...……