Docker、Kubernetes 和 Apache Mesos 對比中的一些誤區

有無數的文章、討論、以及很多社區喋喋不休地比較 Docker、Kubernetes 和 Mesos。如果你只是聽信了隻言片語，你可能會認為這三個開源項目正為了稱霸容器界而殊死搏鬥。你可能還相信從他們中選出一個如宗教信仰般神聖——真正的信徒會忠於他們的信仰，而且會燒死那些敢於考慮替代方案的異教徒。

那都是廢話。

雖然所有這三種技術都使得使用容器來部署、管理和伸縮應用成為可能，但實際上它們各自解決了不同的問題，並且根植於迥異的上下文環境中。事實上，這三種被廣泛採用的工具鏈，都是有差別的。

讓我們重新審視每個項目的原始任務、技術架構，以及它們是如何相互補充和交互的，而不是糾結於比較這些快速迭代的技術之間重疊的特性。

讓我們從 Docker 開始……

Docker 公司，始於名為 dotCloud 的平台即服務（PaaS）供應商。dotCloud 團隊發現，在許多應用和客戶之間管理依賴和二進位文件時需要付出大量的工作。因此他們將 Linux 的 cgroups 和 namespace 的一些功能合併成一個單一且易於使用的軟體包，以便於應用程序可以一致地運行在任何基礎設施上。這個軟體包就是所謂的 Docker 鏡像，它提供了如下的功能：

• 將應用程序和依賴庫封裝在一個軟體包（即 Docker 鏡像）中，因此應用可以被一致地部署在各個環境上；
• 提供類似 Git 的語義，例如 docker push，docker commit 等命令讓應用開發者可以快速接受這門新的技術，並將其融入到現有的工作流中；
• 定義 Docker 鏡像為不可變的層，支持不可變的基礎設施。新提交的變更被分別保存為只讀層，讓復用鏡像和追蹤變更記錄變得十分簡單。層還通過只傳輸更新而不是整個鏡像來節省磁碟空間和網路流量；
• 通過實例化不可變的鏡像和讀寫層來運行 Docker 容器，讀寫層可以臨時地存儲運行時變更，從而輕鬆部署和擴展應用程序的多個實例。

Docker 變得越來越受歡迎，開發者們開始從在筆記本電腦上運行容器轉而在生產環境中運行容器。跨多個機器之間協調這些容器需要額外的工具，這稱之為 容器編排 container orchestration 。有趣的是，第一個支持 Docker 鏡像的容器編排工具（2014 年 6月）是 Apache Mesos 的 Marathon（後面會有詳細介紹) 。那年，Docker 的創始人兼首席技術官 Solomon Hykes 將 Mesos 推薦為「生產集群的黃金標準」。不久之後，除了 Mesos 的 Marathon 之外，還出現了許多的容器編排技術：Nomad、Kubernetes，不出所料還有 Docker Swarm （它如今是 Docker 引擎的一部分）。

隨著 Docker 開始商業化其開源的文件格式（LCTT 譯註：指 Docker 鏡像的 dockerfile 文件格式），該公司還開始引入工具來完善其核心的 Docker 文件格式和運行時引擎，包括：

• 為公開存儲 Docker 鏡像的而生的 Docker hub；
• 存儲私有鏡像的 Docker 倉庫（Docker registry）；
• Docker cloud，用於構建和運行容器的管理性服務；
• Docker 數據中心作為一種商業產品體現了許多 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 （GCP）上提供容器編排「即服務」。 Google 在容器方面擁有豐富的經驗（是他們在 Linux 中引入了 cgroups），但現有的內部容器和 Borg 等分散式計算工具直接與其基礎架構相耦合。所以，Google 沒有使用原有系統的任何代碼，而是從頭開始設計 Kubernetes （K8S）來編排 Docker 容器。 Kubernetes 於 2015 年 2 月發布，其目標和考慮如下：

• 為應用程序開發人員提供編排 Docker 容器的強大工具，而無需與底層基礎設施交互；
• 提供標準部署介面和原語，以實現雲端一致的應用部署體驗和 API;
• 基於模塊化 API 核心，允許供應商圍繞 Kubernetes 的核心技術集成其系統。

2016 年 3 月，Google 將 Kubernetes 捐贈給了 CNCF，並且直到今天仍然是該項目的主要貢獻者（其次是Redhat，CoreOS 等）。

來源: wikipedia

Kubernetes 對應用程序開發人員非常有吸引力，因為它減輕了對基礎架構和運營團隊的依賴程度。供應商也喜歡 Kubernetes，因為它提供了一個容易的方式來擁抱容器化運動，並為客戶部署自己的 Kubernetes（這仍然是一個值得重視的挑戰）提供商業解決方案。 Kubernetes 也是有吸引力的，因為它是 CNCF 旗下的開源項目，與 Docker Swarm 相反，Docker Swarm 儘管是開源的，但是被 Docker 公司緊緊地掌控著。

Kubernetes 的核心優勢是為應用程序開發人員提供了用於編排無狀態 Docker 容器的強大工具。 雖然有多個擴大項目範圍的提議，以提供更多的功能（例如分析和有狀態數據服務），但這些提議仍處於非常早期的階段，它們能取得多大的成功還有待觀察。

Apache Mesos

Apache Mesos 始於 加州大學伯克利分校 UC Berkeley 的下一代容器集群管理器項目，並應用了從雲計算級別的分散式基礎架構（如 Google 的 Borg 和 Facebook 的 Tupperware）中習得的經驗和教訓。 雖然 Borg 和 Tupperware 具有單一的架構，並且是與物理基礎架構緊密結合的閉源專有技術，但 Mesos 推出了一種模塊化架構，一種開源的開發方法，旨在完全獨立於基礎架構。Mesos 迅速被 Twitter、Apple（Siri 中）、Yelp、Uber、Netflix 和許多領先的技術公司採用，支持從微服務、大數據和實時分析到彈性擴展的一切。

作為集群管理器，Mesos 被設計用來解決一系列不同的挑戰：

• 將數據中心資源抽象為單個池來簡化資源分配，同時在私有雲或公有雲中提供一致的應用和運維體驗；
• 在相同的基礎架構上協調多個工作負載，如分析、無狀態微服務、分散式數據服務和傳統應用程序，以提高利用率，降低成本和檯面空間;
• 為應用程序特定的任務（如部署、自我修復、擴展和升級），自動執行第二天的操作；提供高度可用的容錯基礎設施；
• 提供持久的可擴展性來運行新的應用程序和技術，而無需修改集群管理器或其上構建的任何現有應用程序；
• 彈性擴展可以將應用程序和底層基礎設施從少量擴展到數十到數萬個節點。

Mesos 獨有的獨立管理各種工作負載的能力 —— 包括 Java 這樣的傳統應用程序、無狀態 Docker 微服務、批處理作業、實時分析和有狀態的分散式數據服務。Mesos 廣泛的工作負載覆蓋來自於其兩級架構，從而實現了「應用感知」調度。通過將應用程序特定的操作邏輯封裝在「Mesos 框架」（類似於操作中的運行手冊）中來實現應用程序感知調度。資源管理器 Mesos Master 提供了這些框架基礎架構的部分，同時保持隔離。這種方法允許每個工作負載都有自己的專門構建的應用程序調度程序，可以了解其部署、擴展和升級的特定操作要求。應用程序調度程序也是獨立開發、管理和更新的，這讓 Mesos 擁有高度可擴展的能力，支持新的工作負載或隨著時間的推移而增加更多的操作功能。

舉一個團隊如何管理應用軟體升級的例子。無狀態應用程序可以從「藍/綠」部署方案中受益；當新版本的應用運行起來時，原先舊版本的軟體依然還正常運轉著，然後當舊應用被銷毀時流量將會切換到新的應用上。但是升級數據工作負載例如 HDFS 或者 Cassandra 要求節點停機一次，此時需要持久化本地數據卷以防止數據丟失，並且按照特定的順序執行原位升級，在升級之前和升級完成之後，都要在每一個節點類型上執行特定的檢查和命令。任何這些步驟都是應用程序或服務特定的，甚至可能是版本特定的。這讓使用常規容器編排調度程序來管理數據服務變得非常困難。

Mesos 以每一個工作負載所需的特定方式管理各種工作負載，使得許多公司將 Mesos 作為一個統一的平台，將微服務和數據服務結合在一起。數據密集型應用程序的通用參考架構是 「SMACK 家族」（LCTT 譯註：SMACK 即 Spark、Mesos、Akka、Cassandra、Kafka)。

是時候搞清楚這些了

請注意，我們尚未對 Apache Mesos 的容器編排有任何描述。所以為什麼人們會自動地將 Mesos 和容器編排聯繫起來呢？容器編排是可以在 Mesos 的模塊化架構上運行的工作負載的一個例子，它是通過一個專門的編排「框架」來完成的，這個框架就 Marathon，一個構建於 Mesos 之上的工具。 Marathon 最初是為了在 cgroup 容器中編排應用歸檔（如 JAR、tarball、ZIP 文件）而開發的，是 2014 年最先支持 Docker 容器的編排工具之一。

所以當人們將 Docker 和 Kubernetes 與 Mesos 進行比較時，他們實際上是將 Kubernetes 和 Docker Swarm 與在 Mesos 上運行的 Marathon 進行比較。

為什麼搞清楚這一點很重要？ 因為 Mesos 坦率地講並不在乎它上面運行了什麼。 Mesos 可以在共享的基礎設施上彈性地為 Java 應用伺服器提供集群服務、Docker 容器編排、Jenkins 持續集成任務、Apache Spark 分析、Apache Kafka 流，以及更多其他的服務。Mesos 甚至可以運行 Kubernetes 或者其他的容器編排工具，即使公共的集成目前還不可用。

來源: Apache Mesos 2016 調查問卷

Mesos 的另一個考慮因素（也是為什麼它對許多企業架構師來說如此有吸引力）是運行關鍵任務工作負載的成熟度。 Mesos 已經在大規模生產環境下（成千上萬台伺服器）運行了超過 7 年的時間，這就是為什麼它比市場上許多其他的容器技術更具有生產上的可行性和擴展上的可靠性。

我所說的這些什麼意思？

總而言之，所有這三種技術都與 Docker 容器有關，可以讓你在容器編排上實現應用程序的可移植性和擴展性。那麼你在它們之間如何選擇呢？ 歸根到底是為工作選擇合適的工具（也可能是為不同的工作選擇不同的工具）。如果您是一個應用開發人員，正在尋找現代化的方式來構建和打包你的應用程序，或者想加速你的微服務計劃，Docker 容器和開發工具就是最好的選擇。

如果你們是一個開發人員或者 DevOps 的團隊，並希望構建一個專門用於 Docker 容器編排的系統，而且願意花時間折騰集成解決方案與底層基礎設施（或依靠公共雲基礎架構，如 Google 容器引擎（GCE）或 Azure 容器服務（ACS）），Kubernetes 是一個可以考慮的好技術。

如果你們想要建立一個運行多個關鍵任務工作負載的可靠平台，包括 Docker 容器、傳統應用程序（例如 Java）和分散式數據服務（例如 Spark、Kafka、Cassandra、Elastic），並希望所有這些可依移植到雲端提供商或者數據中心，那麼 Mesos（或我們自己的 Mesos 發行版，Mesosphere DC/OS）更適合你們的需求。

無論您選擇什麼，您都將擁抱一套可以更有效地利用伺服器資源的工具，簡化應用程序的可移植性，並提高開發人員的敏捷性。你的選擇真的不會有錯。

via: https://mesosphere.com/blog/docker-vs-kubernetes-vs-apache-mesos/

作者：Amr Abdelrazik 譯者：rieonke 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive