Docker、Kubernetes、ApacheMesos之爭|一個與傳說不同的故事

本文講的是Docker、Kubernetes、Apache Mesos 之爭 | 一個與傳說不同的故事【編者的話】有無數的文章、討論和社交網路上的交流在比較 Docker、Kubernetes 和 Mesos。

【3 天燒腦式基於Docker的CI/CD實戰訓練營 | 北京站】本次培訓圍繞基於Docker的CI/CD實戰展開，具體內容包括：持續整合與持續交付（CI/CD）概覽；持續整合系統介紹；客戶端與服務端的 CI/CD 實踐；開發流程中引入 CI、CD；Gitlab 和 CI、CD 工具；Gitlab CI、Drone 的使用以及實踐經驗分享等。

如果只聽取部分資訊，你會以為這三個開源專案正在為容器世界的霸權而決戰。你也可能認為，選擇其一幾乎是一個宗教選擇；真正的信徒維護他們的信仰，燒死膽敢考慮其它替代品的異端者。

這都是囈語。

雖然三種技術都讓利用容器進行部署、管理和擴充套件應用程式成為可能，其實它們各自解決不同的問題，植根於非常不同的環境背景。事實上，這三種被廣泛採用的工具鏈裡，沒有彼此完全相同的。

與其比較這幾項快速發展的技術的重疊特性，不如讓我們重新審視每個專案的原始使命、架構、以及它們如何互相補充與互動。

從 Docker 說起……

今天的 Docker 公司，起始於一家平臺即服務（Platform-as-a-Service，PaaS）初創公司，叫做 dotCloud。dotCloud 團隊發現，為大量應用程式和大量客戶去管理軟體依賴和二進位制檔案需要許多工作量。因此他們將 Linux cgroups 和名稱空間（Namespace）的功能合併為一個獨立的易用的包，以便應用程式能在任何基礎設施上無差別的執行。

這個包就是 Docker 映象，它提供以下功能：

• 將應用程式和庫封裝進一個包（Docker 映象），應用程式可以一致地部署在多個環境；
• 提供類似 Git 的語義，如 “docker push”、“docker commit”，讓程式開發人員能輕鬆的採用新技術，並納入其現有工作流；
• 將 Docker 映象定義為不可變層，支援不可變基礎設施。釋出的變動儲存在單獨的只讀層，讓重用映象和追蹤變更變得容易。層還能通過只傳輸變更而不是整個映象，節省磁碟空間和網路頻寬；
• 用不可變映象啟動 Docker 容器例項，附帶一個可寫層來臨時儲存執行時更改，讓應用程式快速部署和擴充套件變得容易。

Docker 越來越受歡迎，開發人員由在筆記本上執行容器，開始轉為在生產環境執行容器。這需要額外工具在多機之間協調容器，即容器編排。有趣的是，執行於 Apache Mesos（下文詳述）之上的 Marathon 是支援 Docker 映象（2014年6月）的首批容器編排工具之一。那一年，Docker 的創始人兼 CTO Solomon Hykes 稱讚 Mesos 為“生產叢集的黃金標準”。不久，除執行於 Mesos 之上的 Marathon，還出現了許多容器編排技術：Nomad、Kubernetes，毫不意外，還有 Docker Swarm（現在是 Docker Engine 的一部分）。

隨著 Docker 對開原始檔格式進行商業化，該公司還開始引入工具來補充核心的 Docker 檔案格式和執行引擎，包括：

• Docker hub 用作公共 Docker 映象儲存；
• Docker registry 用作內部 Docker 映象儲存；
• Docker cloud，用於構建和執行容器的託管服務；
• Docker datacenter 作為商業產品內建提供眾多 Docker 技術。

_來源：www.docker.com._

Docker 很有遠見，它將軟體以及相關依賴封裝到了一個包中，這種方式顛覆了軟體行業規則；正如 mp3 幫助重塑了音樂行業一樣。Docker 檔案格式成為行業標準，主要的容器技術廠商（包括 Docker、Google、Pivotal、Mesosphere 等）成立了 Cloud Native Computing Foundation (CNCF) 和 Open Container Initiative (OCI)。

今天，CNCF 和 OCI 旨在確保容器技術之間的互操作性和標準介面，並確保使用任何工具構建的 Docker 容器可以執行在任何執行環境和基礎架構上。

步入 Kubernetes

Google 很早就認識到了 Docker 映象的潛力，並設法在 Google Cloud Platform 上實現容器編排“即服務”。Google 雖然在容器方面有著深厚的經驗（是他們在 Linux 中引入了 cgroups），但它現有的內部容器和 Borg 等分散式計算工具是和基礎設施緊密耦合的。

因此，Google 沒有使用任何現有系統的程式碼，而是重新設計了 Kubernetes 對 Docker 容器進行編排。Kubernetes 是在 2015 年 2 月正式釋出的，它的目標和構想是：

• 為廣大應用開發者提供一個強大的工具來管理 Docker 容器的編排，而不再需要和底層基礎架構進行互動；
• 提供標準的部署介面和元語，以獲得一致的應用部署的體驗和跨雲的 API；
• 建立一個模組化的 API 核心，允許廠商以 Kubernetes 技術為核心進行系統整合。

2016 年 3 月，Google 向 CNCF 捐贈了 Kubernetes，直到今天仍然保持著在這個專案的貢獻者中首位的位置（其後是紅帽，CoreOS 等）。

_來源：wikipedia_

應用開發者對 Kubernetes 產生了很大的興趣，因為 Kubernetes 降低了他們對基礎架構和運維團隊的依賴。廠商也很喜歡 Kubernetes，因為它讓擁抱容器化技術變的簡單，併為客戶部署自己的 Kubernetes 提供了商業解決方案 （這是很有價值的事情）。Kubernetes 吸引大家的另外一個原因是，它是 CNCF 旗下的開源專案，這與 Docker Swarm 完全不同，Docker Swarm 儘管是開源的，但是卻被 Docker 公司牢牢地掌控著。

Kubernetes 的核心優勢是為應用開發者提供強大的工具來編排無狀態的 Docker 容器。雖然已經有了多個提議，希望擴大這個專案的範圍（比如資料分析和有狀態的資料服務），這些提議仍然處於非常早期的階段，能不能成功我們還需要保持觀望。

Apache Mesos

Apache Mesos 是加州大學伯克利分校為了研發新一代叢集管理器而發起的專案，它借鑑了 Google Borg 系統和 Facebook’s Tupperware 系統中大規模、分散式計算架構的相關經驗，並把它應用到了 Mesos 上。
當時 Borg 和 Tupperware 還是一個和基礎設施緊密繫結，架構龐大，並且技術閉源的系統，而 Mesos 引入了模組化的架構，開源的開發方式，和完全獨立於底層基礎設施的設計。為了使基礎架構能夠動態靈活擴充套件，Twitter、Apple(Siri)、Yelp、Uber、Netflix 等高科技公司很快就把 Mesos 應用到微服務、大資料計算、實時分析等業務上。

Mesos 作為一個叢集資源管理器，它從架構層面解決了以下一系列的難題和挑戰：

• 為了簡化資源分配，Mesos 將整個資料中心資源抽象為一個資源池，同時為私有云和公有云提供了一致的應用和操作體驗；
• Mesos 將多種型別的工作任務執行在同一個基礎設施上，比如資料分析，無狀態微服務，分散式資料服務和傳統應用程式，以便提高資源利用率，降低成本；
• 自動化 day-two operations（如部署，自我修復，擴充套件和升級），以保證架構的高可用性和容錯性；

  （譯者注：Day 2 operation——指對服務的精細化運營操作，包括日誌收集、監控和分析、服務效能監控報警等，具體可以檢視 DCOS Day 2 operation 官方文件 ）

• 提供了有效的擴充套件性來執行新的應用程式而無需修改群集管理器和執行在它上面的的已有應用程式；
• 彈性的的擴充套件應用程式和底層基礎架構，可以從幾個節點擴充套件到數十個，甚至上萬個節點。

Mesos 具有一種獨特的能力，它可以獨自管理不同型別的工作任務，包括傳統應用程式，如 Java，無狀態的 Docker 微服務，批處理作業，實時分析服務和有狀態的分散式資料服務。Mesos 之所以能支援多種型別的工作任務，與它的兩級架構設計密切相關，這種架構可以使應用在有感知的情況下完成資源排程。

這種排程方法是通過將應用程式特定的操作邏輯封裝在“Mesos 框架”（類似於操作中的執行手冊）中來實現的。然後，資源管理器 Mesos Master 在保持隔離的同時會把框架基礎架構的這部分資源共享出來。這種方法允許每個工作任務都有自己的專門排程器，這個排程器清楚其如何部署，擴充套件和升級等特定操作需求。應用程式的排程器也是獨立開發，管理和更新的，這樣的設計使得 Mesos 具有高度的可擴充套件性，支援新的工作任務，或許將來會增加更多的功能特性。

以團隊內部如何管理服務升級為例：無狀態的應用可以從“blue/green”部署方法中獲益；當舊的應用程式還執行著的時候，一個新版本完全執行起來時，流量會在舊程式銷燬時完全切換到新版本的應用中。但升級資料型工作任務時（如 HDFS， Cassandra），每次要先拿掉一個節點，保留一份本地資料卷以避免資料丟失，按照順序逐個升級下線的節點，同時要在每個節點升級前後執行指定的檢測命令。

這些升級步驟都是和應用程式或服務相關聯的，甚至和特定版本相關。
這使得使用常規容器編排管理這些資料服務變得異常困難。

Mesos 的這種保持每個工作任務以它自己的方式來管理資源排程的特性，使得許多公司將 Mesos 作為一個統一的平臺，將微服務和資料服務同時執行在上面。
有一個類似的資料密集型架構可以參考，“SMACK stack”，即 Spark、Mesos、Akka、Cassandra、Kafka 技術棧。

幾點宣告

請注意，我們在描述 Apache Mesos 時並未提及任何有關容器編排的內容。那為什麼大家總是下意識把容器編排和 Mesos 關聯起來呢？Mesos 的模組化架構使它能夠執行多種工作任務，容器編排就是其中一個例子，它是通過執行在 Mesos 上的一個叫做 Marathon 的特殊框架來實現的。Marathon 最初在 cgroup 容器中管理應用程式包（例如 JAR 包、TAR 包及 ZIP 檔案），也是第一個支援 Docker 容器的容器編排工具（2014 年）。

所以當人們用 Docker、Kubernetes 同 Mesos 比較時，實際上比較的是 Kubernetes、Docker Swarm 和執行在 Mesos 上的 Marathon。

為什麼這點很重要？坦率的講，因為 Mesos 並不關心執行在上面的是什麼。Mesos 可以彈性地為執行在共享基礎設施上的 Java 應用伺服器、Docker 容器編排、Jenkins CI 作業、Apache Spark 實時分析、Apache Kafka 流處理等任務提供叢集服務。Mesos 上甚至可以執行 Kubernetes 和其它的一些容器編排工具，儘管目前還沒有公認的整合方案。

_來源：Apache Mesos Survey 2016_

另一個值得考慮 Mesos 的因素（也是吸引大量企業架構師的原因）是其執行關鍵性任務的成熟度。Mesos 已經在大規模的生產環境（成千上萬臺伺服器）中執行了 7 年多，這也是市場上認定 Mesos 比其他容器編排技術在生產環境實用性和大規模穩定性更有優勢的原因。

這些都意味著什麼？

綜上所述，這三種技術全都與 Docker 容器有關，並允許你使用容器編排實現應用程式可移植和擴充套件。那麼從它們中如何來選擇呢？歸結為一句話：依據任務型別選擇合適工具（甚至為不同的任務選擇各自的工具）。如果你是應用程式開發者，正在尋找最新的方法來構建和打包應用程式，或加速邁出微服務的第一步，Docker 容器格式和開發工具是最好的方法。

如果是開發／DevOps 團隊，希望構建一套專用於 Docker 容器編排的系統，並願意著手將你的解決方案與底層基礎設施進行整合（或依賴於 Google Container Engine、Azure Container Service 之類的公共雲基礎設施），Kubernetes 是值得你考慮的技術選擇。

如果你希望建立一個可靠的平臺，同時執行包括 Docker 容器、傳統應用程式（如 Java）和分散式資料服務（如 Spark、Kafka、Cassandra、Elastic）在內的多項關鍵任務，並希望這些全部可以跨雲服務商和／或跨資料中心移植，那麼 Mesos（或 Mesosphere DC/OS）正好適合你。

無論作何選擇，你都將擁有一整套工具，去更有效的利用伺服器資源、簡化應用程式移植、並提高開發者靈活性。
你絕對不會錯。

原文連結：Docker vs. Kubernetes vs. Apache Mesos: Why What You Think You Know is Probably Wrong（譯者：@Lax、 @zousheng、 @douzl 和 @suisuihan）

原文釋出時間為：2017-08-04

本文作者：Lax

本文來自雲棲社群合作伙伴Dockerone.io，瞭解相關資訊可以關注Dockerone.io。

原文標題：Docker、Kubernetes、Apache Mesos 之爭 | 一個與傳說不同的故事