點擊上方“CSDN”， 選擇“置頂公眾號”
關鍵時刻， 第一時間送達！
作者丨Amr Abdelrazik
譯者丨Teixeira10
【譯者注】作者對Docker、Kubernetes和Mesos三種技術的發展過程、技術原理以及技術特點進行介紹， 並針對不同的適用場景和技術特性給開發人員進行合理的推薦。 以下為譯文：
有無數的文章、議題和大量的社交聊天中都會將Docker、Kubernetes和Mesos進行比較。 如果你也從中瞭解過， 你會認為這三個開源專案正在為爭奪容器的霸主地位而戰。 你可能也會覺得， 只選擇其中一個技術， 這會是一個謹慎的決定；當然也有一些人為了支援他們所選擇的技術而去否認其他兩種技術。
顯然， 這些做法都是不對的。
儘管這三種技術都能實現容器部署、管理和擴展應用程式， 但實際上它們各自解決了不同的問題， 並且應用于完全不同的環境中。 事實上， 這三種被廣泛採用的技術， 沒有一種與其他是完全相同的。
與其比較這些快速發展的技術重疊特性， 不如讓我們回顧一下每個項目的原始任務、體系結構以及它們如何相互補充和相互作用的。
讓我們先從Docker開始
Docker Inc是一家名為dotCloud的平臺服務初創公司。 其團隊發現， 在許多應用程式和客戶之間的管理依賴關係和二進位檔案裡需要付出巨大的努力。 因此， 他們將Linux cgroups和命名空間的一些功能組合到一個單一且易於使用的包中， 這樣應用程式就可以在任何基礎設施上持續運行。
將應用程式和庫打包在單個包中（Docker鏡像）， 因此應用程式可以一致地部署在許多環境中
提供諸如“docker push”、“docker commit”等類似於“docker”的語義， 讓開發人員可以輕鬆地採用新技術， 並將其集成到現有工作流中
將Docker鏡像定義為不可變層， 支援不可變基礎結構。 已提交的更新會存儲為一個單獨的唯讀層， 這使得重用鏡像和跟蹤更改變得很容易。 層之間還能通過傳輸更新而不是傳輸整個鏡像， 來節省磁碟空間和網路流量
通過產生實體不可變的鏡像運行Docker容器， 它使用一個可寫層臨時存儲運行時的變動， 從而可以快速部署和擴展應用程式的多個實例。
Docker越來越受歡迎， 開發人員開始從在筆記型電腦上運行，
Docker hub， 用於Docker鏡像的公共存儲
Docker registry， 用於存儲本地部署
Docker cloud， 一種用於構建和運行容器的管理服務
Docker datacenter ， 作為一項商業服務， 體現了許多Docker技術
Source: www.docker.com
Docker將軟體及其依賴包封裝在單個包中， 這對軟體行業來說是一個遊戲規則的改變；同樣的方式， mp3也説明重塑了音樂產業。 Docker檔案格式成為行業標準， 領先的容器技術供應商（包括Docker、Google、Pivotal、Mesosphere以及其他）形成了Cloud Native Computing Foundation （CNCF）和Open container Initiative（OCI）。 今天， CNCF和OCI的目標是確保跨容器技術的互通性和標準化介面， 並確保使用任何工具構建的Docker容器能夠在任何時間或基礎設施上運行。
Enter Kubernetes
Google在早期就意識到了Docker鏡像的潛力， 並希望在Google雲平臺上提供“as-a-service”的服務。 谷歌在容器方面有豐富的經驗（他們在Linux中引入了cgroups）， 但現有的內部容器和分散式運算工具， 如Borg， 會直接與他們的基礎設施連接。 因此， 谷歌沒有使用現有系統中的任何代碼， 而是從零開始設計了Kubernetes來編排Docker容器。 Kubernetes於2015年2月發佈， 包含以下目標和注意事項：
授權應用程式開發人員使用Docker容器提供的強大工具， 而無需與底層基礎設施進行交互
為一致的應用程式部署和跨雲的api提供標準的部署介面和原語
構建一個模組化的API核心， 允許供應商圍繞核心的Kubernetes技術集成系統。 到2016年3月， 穀歌將Kubernetes捐贈給了CNCF， 它到今天為止仍然是該項目的主要貢獻者（其次是Redhat、CoreOS以及其他）。
Source: wikipedia
Kubernetes對應用程式開發人員來說，非常有吸引力，因為它減少了對基礎設施和操作團隊的依賴。廠商也喜歡Kubernetes，因為它提供了一種簡單的方式來支援容器移動，並為運行自己的Kubernetes部署的操作提供了一個商業解決方案（這仍然是一個不平凡的經驗）。Kubernetes也是很有吸引力的，因為它是CNCF下的開源項目，與Docker集群相比，後者的開源專案受到Docker公司的嚴格控制。
Kubernetes的核心優勢在於為應用程式開發人員提供了強大的工具，用於編排無狀態的Docker容器。儘管計畫擴展更多的工作負載範圍（例如分析和狀態資料服務），但是這些計畫仍然處於非常早期的階段，並且還有待觀察它們的成功程度。
Apache Mesos
Apache Mesos最初是加州大學伯克利分校的一個專案，目的是創建下一代集群管理器，並且有來自雲計算、分散式運算基礎設施中學習的經驗，比如穀歌的Borg和Facebook的Tupperware。雖然Borg和Tupperware有單一的體系結構，而且是與物理基礎設施相關的封閉的專有技術，但Mesos引入了一種模組化的體系結構，一種開源的開發方法，並被設計為完全獨立於底層的基礎設施。Mesos很快被Twitter、蘋果（Siri）、Yelp、優步、Netflix等許多領先的科技公司所接受，涉及到很多領域，從微服務、大資料和即時分析等。
作為一個集群管理器，Mesos的架構是為了解決一系列不同的難題：
將資料中心資源抽象為單個池，以簡化資源配置，同時提供跨私有或公共雲的一致應用程式和操作經驗
在相同的基礎設施上使用不同的工作負載，比如分析、無狀態的微服務、分散式資料服務和傳統應用程式，以提高利用率，降低成本和佔用空間
針對特定應用程式的任務，例如部署、自愈、擴展和升級，可以自動執行day-two操作；提供高可用性容錯基礎設施
在不修改集群管理器或任何現有應用程式的基礎上，提供用於運行新應用程式和技術的永久可擴展性
可彈性地規劃應用程式和底層基礎設施，從少數幾個，到數十個，甚至到數萬個。
Mesos具有獨特的能力，可以單獨管理各種不同的工作負載，包括傳統的應用程式，如Java、無狀態Docker微服務、批次處理工作、即時分析和狀態分散式資料服務等。Mesos的廣泛工作負載來自於它的兩層架構，這使 “application-aware”得以調度。application-aware的調度是通過將特定的應用程式的操作邏輯封裝在“Mesos框架”中（類似於操作中的runbook）來完成的。Mesos Master，資源管理器，在保持隔離的情況下，為這些框架提供了一部分底層基礎設施。這種方法允許每個工作負載都有自己專用的應用程式調度器，從而可以理解它的部署、擴展和升級的特定操作需求。應用調度程式的開發、管理和更新都是獨立的，這也就允許Mesos具有高度的可擴展性，來支援新的工作負載，同時增加更多的操作能力。
舉例來說，一個團隊如何管理升級程式。無狀態應用程式可以從“blue/green”部署方法中獲益；這款應用的另一個完整版本在舊版本還存在的時候就會出現，當用戶準備好時，打開網路會搜索到新版本，舊應用也就會被覆蓋。但是，像HDFS或Cassandra這樣進行升級資料工作時，需要將節點離線一次，來保持本地的資料量，避免資料丟失，同時執行一個特定的操作，並在升級之前和之後對每個節點執行特殊的檢查和命令。這些步驟中都是需要特定的應用程式或服務的，甚至可能是特定的版本。這使得使用傳統的容器來管理資料服務變得異常困難。
Mesos有能力管理每一個工作，這使得許多公司都將Mesos作為一個統一的平臺，將微服務和資料服務結合在一起。“SMACK stack”是用於運行資料密集型應用程式的通用參考體系結構。
一個清晰明朗的時刻
我們還沒有介紹過Apache Mesos的容器編排該如何描述。那麼，為什麼人們會自動將Mesos與容器編排聯繫起來呢？容器編排是可以在Mesos的模組化體系結構上運行的，它使用了一個專門基於Mesos的編排框架，叫做Marathon。Marathon最初是為了在cgroup容器中編排應用程式存檔（如jar、tarball、ZIP文件）而開發的，並在2014年成為首批支援Docker容器的容器協調器之一。
因此，當人們將Kubernetes和Kubernete與Mesos進行比較時，他們實際上是在把Docker和 Docker Swarm與運行在Mesos上的Marathon進行比較。
為什麼這很重要?因為坦白地說，Mesos並不關心誰會在它的基礎上運行。Mesos可以為Java應用伺服器提供集群服務、Docker容器編排、 Jenkins CI Jobs、Apache Spark analytics， Apache Kafka streaming，以及更多的共用基礎設施。Mesos甚至可以運行在Kubernetes或其他容器的組合器上，儘管目前公共集成還未實現。
Source: Apache Mesos Survey 2016
Mesos的另一個優勢（以及為什麼它對許多企業架構師有吸引力）是它在運行關鍵任務時的成熟度。Mesos已經在大規模生產（數萬台伺服器），已經超過7年的時間，這就是為什麼我們知道，在市場上，它比其他許多的容器技術更成熟，更可靠。
這些都意味著什麼？
總之，這三種技術都與Docker容器有關，並為應用程式的可攜性和規模提供了容器編排。那麼如何在他們之間做出選擇呢?這要很據當時的工作選擇合適的工具（對於不同的工作，是需要選擇不同的工具的）。如果您是一名應用程式開發人員，想尋找一種現代的方式來構建和打包應用程式，或者加速微服務，那麼Docker容器和開發工具就是最好的選擇。
如果你是一個dev / devops團隊，想要搭建一個系統致力於Docker容器編排，並願意親力親為底層基礎設施的集成解決方案（或依賴於公共雲基礎設施，如穀歌引擎或Azure容器服務），Kubernetes是你值得考慮的好技術。
如果您想構建一個可靠的平臺，可以運行多個關鍵任務，包括Docker容器、遺留程式（例如：Java）和分散式資料服務（例如：Spark， Kafka， Cassandra， Elastic），並想要可移植的雲服務或資料中心，那麼Mesos（或者我們自己的Mesos分佈， Mesosphere DC/OS）是適合你的。
無論您選擇什麼，您都將使用一系列工具，這些工具可以更有效地利用伺服器資源，簡化應用程式的可攜性，並提高開發人員的敏捷性。這樣，你真的不太可能出錯。
Source: wikipedia
Kubernetes對應用程式開發人員來說，非常有吸引力，因為它減少了對基礎設施和操作團隊的依賴。廠商也喜歡Kubernetes，因為它提供了一種簡單的方式來支援容器移動，並為運行自己的Kubernetes部署的操作提供了一個商業解決方案（這仍然是一個不平凡的經驗）。Kubernetes也是很有吸引力的，因為它是CNCF下的開源項目，與Docker集群相比，後者的開源專案受到Docker公司的嚴格控制。
Kubernetes的核心優勢在於為應用程式開發人員提供了強大的工具，用於編排無狀態的Docker容器。儘管計畫擴展更多的工作負載範圍（例如分析和狀態資料服務），但是這些計畫仍然處於非常早期的階段，並且還有待觀察它們的成功程度。
Apache Mesos
Apache Mesos最初是加州大學伯克利分校的一個專案，目的是創建下一代集群管理器，並且有來自雲計算、分散式運算基礎設施中學習的經驗，比如穀歌的Borg和Facebook的Tupperware。雖然Borg和Tupperware有單一的體系結構，而且是與物理基礎設施相關的封閉的專有技術，但Mesos引入了一種模組化的體系結構，一種開源的開發方法，並被設計為完全獨立於底層的基礎設施。Mesos很快被Twitter、蘋果（Siri）、Yelp、優步、Netflix等許多領先的科技公司所接受，涉及到很多領域，從微服務、大資料和即時分析等。
作為一個集群管理器，Mesos的架構是為了解決一系列不同的難題：
將資料中心資源抽象為單個池，以簡化資源配置，同時提供跨私有或公共雲的一致應用程式和操作經驗
在相同的基礎設施上使用不同的工作負載，比如分析、無狀態的微服務、分散式資料服務和傳統應用程式，以提高利用率，降低成本和佔用空間
針對特定應用程式的任務，例如部署、自愈、擴展和升級，可以自動執行day-two操作；提供高可用性容錯基礎設施
在不修改集群管理器或任何現有應用程式的基礎上，提供用於運行新應用程式和技術的永久可擴展性
可彈性地規劃應用程式和底層基礎設施，從少數幾個，到數十個，甚至到數萬個。
Mesos具有獨特的能力，可以單獨管理各種不同的工作負載，包括傳統的應用程式，如Java、無狀態Docker微服務、批次處理工作、即時分析和狀態分散式資料服務等。Mesos的廣泛工作負載來自於它的兩層架構，這使 “application-aware”得以調度。application-aware的調度是通過將特定的應用程式的操作邏輯封裝在“Mesos框架”中（類似於操作中的runbook）來完成的。Mesos Master，資源管理器，在保持隔離的情況下，為這些框架提供了一部分底層基礎設施。這種方法允許每個工作負載都有自己專用的應用程式調度器，從而可以理解它的部署、擴展和升級的特定操作需求。應用調度程式的開發、管理和更新都是獨立的，這也就允許Mesos具有高度的可擴展性，來支援新的工作負載，同時增加更多的操作能力。
舉例來說，一個團隊如何管理升級程式。無狀態應用程式可以從“blue/green”部署方法中獲益；這款應用的另一個完整版本在舊版本還存在的時候就會出現，當用戶準備好時，打開網路會搜索到新版本，舊應用也就會被覆蓋。但是，像HDFS或Cassandra這樣進行升級資料工作時，需要將節點離線一次，來保持本地的資料量，避免資料丟失，同時執行一個特定的操作，並在升級之前和之後對每個節點執行特殊的檢查和命令。這些步驟中都是需要特定的應用程式或服務的，甚至可能是特定的版本。這使得使用傳統的容器來管理資料服務變得異常困難。
Mesos有能力管理每一個工作，這使得許多公司都將Mesos作為一個統一的平臺，將微服務和資料服務結合在一起。“SMACK stack”是用於運行資料密集型應用程式的通用參考體系結構。
一個清晰明朗的時刻
我們還沒有介紹過Apache Mesos的容器編排該如何描述。那麼，為什麼人們會自動將Mesos與容器編排聯繫起來呢？容器編排是可以在Mesos的模組化體系結構上運行的，它使用了一個專門基於Mesos的編排框架，叫做Marathon。Marathon最初是為了在cgroup容器中編排應用程式存檔（如jar、tarball、ZIP文件）而開發的，並在2014年成為首批支援Docker容器的容器協調器之一。
因此，當人們將Kubernetes和Kubernete與Mesos進行比較時，他們實際上是在把Docker和 Docker Swarm與運行在Mesos上的Marathon進行比較。
為什麼這很重要?因為坦白地說，Mesos並不關心誰會在它的基礎上運行。Mesos可以為Java應用伺服器提供集群服務、Docker容器編排、 Jenkins CI Jobs、Apache Spark analytics， Apache Kafka streaming，以及更多的共用基礎設施。Mesos甚至可以運行在Kubernetes或其他容器的組合器上，儘管目前公共集成還未實現。
Source: Apache Mesos Survey 2016
Mesos的另一個優勢（以及為什麼它對許多企業架構師有吸引力）是它在運行關鍵任務時的成熟度。Mesos已經在大規模生產（數萬台伺服器），已經超過7年的時間，這就是為什麼我們知道，在市場上，它比其他許多的容器技術更成熟，更可靠。
這些都意味著什麼？
總之，這三種技術都與Docker容器有關，並為應用程式的可攜性和規模提供了容器編排。那麼如何在他們之間做出選擇呢?這要很據當時的工作選擇合適的工具（對於不同的工作，是需要選擇不同的工具的）。如果您是一名應用程式開發人員，想尋找一種現代的方式來構建和打包應用程式，或者加速微服務，那麼Docker容器和開發工具就是最好的選擇。
如果你是一個dev / devops團隊，想要搭建一個系統致力於Docker容器編排，並願意親力親為底層基礎設施的集成解決方案（或依賴於公共雲基礎設施，如穀歌引擎或Azure容器服務），Kubernetes是你值得考慮的好技術。
如果您想構建一個可靠的平臺，可以運行多個關鍵任務，包括Docker容器、遺留程式（例如：Java）和分散式資料服務（例如：Spark， Kafka， Cassandra， Elastic），並想要可移植的雲服務或資料中心，那麼Mesos（或者我們自己的Mesos分佈， Mesosphere DC/OS）是適合你的。
無論您選擇什麼，您都將使用一系列工具，這些工具可以更有效地利用伺服器資源，簡化應用程式的可攜性，並提高開發人員的敏捷性。這樣，你真的不太可能出錯。