根據 451 Research，2016年，容器技術市場產生了7.62億美元的收入。到2020年，分析公司預測，容器的年度收入將達到27億美元，複合年增長率為40％。

容器市場大好，但是我們面臨兩個問題：如何確保這些容器的安全性？以及如何部署管理它們？

想要解決問題。首先，我們需要建立——

容器策略：您希望在哪裡運用容器？每個 CPU 應分配多少個？ 所有這些問題，都可以通過設定正確的容器策略進行回答。

互操作性：當然，他們應該與您現有的 IT 管理工具協同運作。

OK，在有了明確的需求之後，我們就可以對目前主流的容器編排工具——Kubernetes、Mesosphere Marathon 和 Docker Swarm 進行進一步篩選，他們都可以在不改變原有架構的情況下對容器進行編排管理。

Docker Swarm

如果你剛開始接觸容器，最初瞭解到的應該是 ，作為很多人的入門級容器，它吸引了大量的使用者。 而 Swarm 是 Docker 本地的編排工具，算得上是 Docker 本地的叢集管理器。

Docker Swarm 在2016年6月（1.12）版本中將其功能整合到完整的 Docker 應用程式中，並花了大量的精力來解決啟動和執行。雖然幾個新產品有啟動問題，比如服務發現程式（例如 Consul 或 CoreOSetcd）是在 Docker Swarm 啟動之前執行。Sysadmins 發現這個問題很難解決，即使解決這些啟動問題，也還是需要花費大量的精力部署 Swarm。

所以，即便新的 Docker Swarm 努力獲取使用者，但目前它仍然落後於 Mesosphere 的中央作業系統（DC / OS）和 Kubernetes，但是誰能保證以後不發生變化呢？ 畢竟新改進的 Docker Swarm 確實在部署的便利性上有了提升。 我之前跟幾個 DevOps 談過，他們認為，與 Kubernetes 或 Mesos 叢集相比，Docker Swarm 是一個快進版本。

所以，如果你已經是一個有經驗的 Docker 使用者，Swarm 的學習曲線對你來說就很容易。 Docker Native Orchestration 使用單節點 Docker 概念，並將它們擴充套件到 Swarm。 但一旦你有在執行的 Docker 節點，Swarm 的設定就十分繁瑣。 例如，您可以使用單個 shell 命令將 Docker 例項新增到 Swarm 叢集。 更新的 Swarm 還支援滾動更新，包括節點之間的傳輸層安全加密，以及簡單的負載平衡和相對容易的服務抽象。

目前，Swarm 還有改進的餘地。 例如，它當前不支援執行狀況檢查和自動回滾。 Swarm 使用者也抱怨很多實現問題。例如， Swarm 不能正確支援多主機容器網路等。

Docker Swarm 是內建在 Docker 中的，這應該是它最大的吸引力。 不過，潛在使用者應該注意的是，它就是一個執行的工作，而不是一個立馬能解決您容器部署和管理問題的解決方案。

Mesosphere Marathon

Marathon 是一個用於 Mesosphere DC / OS 和 Apache Mesos 的容器編排平臺。 DC / OS 是基於 Mesos 分散式系統核心的分散式作業系統。 Mesos 也是一個開源叢集管理系統。 Marathon（通過其合作伙伴計劃，Chronos，容錯作業排程程式）提供有狀態應用程式和基於容器的無狀態應用程式之間的管理整合。

Marathon 的出現實際上早於容器。 Mesosphere 聯合創始人和首席技術官 Tobias Knaup 在最近的一次採訪中解釋說，“Marathon 從一開始就被設計為一個通用的工作負載管理器，甚至在 Docker 出名之前。 他們的目標是建立一個橋樑，連通舊世界到新世界，使現有的應用程式可以部署和擴充套件，不需要進行太大的變化。“在 Knaup 看來，無論它是不是一個現代應用程式架構（如微服務或更傳統的三層企業應用程式），至少它非常適合長時間執行。

Marathon 有一個使用者介面，您可以將其視為一個應用程式，它可以看作一個框架來管理容器。這涉及DevOps 的開發人員方面，因為容器通過 REST API 與 Marathon 一起工作。

Marathon 具有許多功能，包括高可用性，服務發現和負載平衡。 如果在 DC / OS 上執行它，您的應用程式也會獲得虛擬 IP 路由。

作為一個更成熟的專案，Marathon 沒有 Docker Swarm 的初期問題。 另一方面，Marathon 有一個更陡峭的學習曲線。 由於 Marathon 只能在帶有 Mesos 的軟體堆疊上執行，這增加了另一層的複雜性。最後，一些功能（例如身份驗證）僅適用於 DC / OS 上的Marathon。 這為你的堆疊又增加了一個抽象層。

Kubernetes

。（開源之前，Kubernetes 的名字叫做“專案7”，是 Borg 的友好版本）。

Google 在建立 Kubernetes 中的作用並不令人感到驚異。很久以前 Docker 使得容器流行起來，Google 的很多專案——搜尋、Gmail、Google 文件都使用了容器技術。 Borg，以及和它的開源的繼承者 Kubernetes，管理著數十億個容器。

Kubernetes 自推出以來，就被移植到 Azure，DC / OS 以及幾乎所有叫得出名字的雲平臺。 唯一的例外是 Amazon WebServices（AWS）。 即使在那裡，CoreOS 也讓使用者在 AWS 上部署 Kubernetes 叢集。

Kubernetes 有巨大的供應商支援。 今天，Kubernetes 由 Linux 基金會託管。 此外，還有來自眾多公司的 Kubernetes 發行版，包括Red Hat OpenShift，Canonical 公司的 Kubernetes 發行版，CoreOS Tectonic 以及英特爾和 Mirantis。

為什麼？ 除了證明自身在 Google 的大型資料中心，Kubernetes 擁有自我修復，自動化推出和回滾和儲存編排。功能列表還在繼續更新。 簡而言之，無論你想用你的容器做什麼，Kubernetes 都可以對它進行管理。

互操作性也是 Kubernetes 一個巨大的亮點。 Sam Ghods 是基礎架構即服務（IaaS）雲提供商 Box 的聯合創始人，他稱讚 Kubernetes，他說：“我可以編寫一個 JSON 規範，並將其提交給任何地方執行的任何 Kubernetes 叢集，還能夠重新建立正確的拓撲和完全正確的我需要的基礎設施。”

Kubernetes 的另一個優點是“對每朵雲的友好性，”軟體工程師 Erez Rabih 說，“你可以在 AWS，GoogleCloud，Microsoft 的 Azure、Rackspace 上執行你的叢集。”事實上，Kubernetes 開發人員的短期目標是使你能夠執行 Docker 容器，由 Kubernetes 管理，同時在多個雲架構上使用群集聯盟。

當然，Kubernetes 並不是完美的。 首先，它有兩個問題。 第一，負載平衡很困難。 到最後，Kubernetes 的進入將使得 Kubernetes 從內部執行到外部的負載均衡器變得容易，但這還是一個在逐步改進的工作。 第二，Kubernetes 擅長自動修復問題。 但它執行非常好，並且可以快速地對容器進行重啟，以至於你不會注意到你的容器崩潰。 當然，為了解決這個問題，您需要新增一個集中式日誌系統。

最後，這三種容器管理工具都與多個雲平臺配合使用，包括 OpenStack、Magnum 和 Azure 容器服務。

好了！在這麼多分析之後，問題來了，哪一個平臺最適合你呢？

Kubernetes 的首席工程師 Brendan Burns 顯然堅持自己的偏愛，但他總結了這些容器管理系統之間的差異：“Mesos 和 Kubernetes 主要旨在解決執行叢集應用程式的類似問題; 他們有不同的發展歷史和不同的方法來解決這個問題。Mesos 的集中力量在通用排程，插入多個不同的排程器。“

相比之下，Burns 說，”Kubernetes 的設計理念是，構建分散式應用程式的環境。它包括用於複製和服務發現作為核心原理，而這是通過 Mesos 中的框架新增的。Swarm 是 Docker 努力擴充套件現有的 Docker API，使一群機器看起來像一個單一的 Docker API。

從支援檢視和功能列表比較來看，贏家顯然是 Kubernetes。 在 AWS 和 Docker 之外，所有人都支援它。

幸運的是，您可以混合和匹配這些程式，滿足您公司需求。三者之間可以很好地進行協同工作。這不容易，但它是可行的 ——也許這也是探索三者之間哪個更適合你的最佳方式。

但是，和往常一樣，最佳選擇取決於您的具體需求。例如，如果你的公司有工作人員精通 Docker，可以選擇執行在 Docker Swarm 上。因為假如它執行得很好，那為什麼還要切換到另一個系統？ 況且 Docker 一直都會被使用。 Marathon 有它的優勢，為你提供一種方式（雖然是多層次的方式）來處理你的容器和你的舊應用程式。

我無法給你一容易的“這才是真正的方式”的答案。你要逐一檢查它們，來找出哪個容器管理工具或工具滿足自己的需要。

我可以告訴你，如果你搬到容器，你肯定會需要這些程式。你也不想浪費你的時間來構建自己的容器管理工具的吧。

所以，選擇哪個呢？ Good luck！