容器集群管理平台的比較

容器化和微服務是當前最熱話題，不久之前，筆者（據說因為現在都不用筆了，「筆者」的稱謂已經不合適了，因為輸入用鍵盤，叫「鍵人」更為合適）參加QCon上海一個微服務監控的Session，場面爆棚，我不得不在擁擠的過道聽完了整個session。隨著要管理的容器越來越多，容器的集群管理平台成為了剛需！

Docker Swarm

Swarm是Docker公司在2014年12月初新發布的容器集群管理工具。它可以把多個主機變成一個虛擬的Docker主機來管理。Swarm使用Go語言開發，並且開源，在github上可以找到它的全部source code。Swarm使用標準的Docker API，給Docker用戶帶來無縫的集群使用體驗。2016年7月， Swarm已經被整合進入Docker Engine。

功能

Docker Swarm提供API 和CLI來在管理運行Docker的集群，它的功能和使用本地的Docker並沒有本質的區別。但是可以通過增加Node帶來和好的擴展性。理論上，你可以通過增加節點（Node）的方式擁有一個無限大的Docker主機。

Swarm並不提供UI，需要UI的話，可以安裝UCP，不過很不幸，這個UCP是收費的。

架構

Swarm的架構並不複雜，可以說非常簡單。Manager負責容器的調度，Node負責容器的運行，Node運行Docker Daemon和Manager之間通過HTTP來通信。Docker Client通過Manager上暴露的標準Docker API來使用Docker的功能。

Swarm的集群協調和業務發現可以支持不同的第三方組件，包括：

• Consul
• Etcd
• ZooKeeper
• Docker Hub

如果對集群協調的概念不熟悉，可以參考我的另一篇博客《使用Python進行分散式系統協調 （ZooKeeper，Consul， etcd ）》

Swarm的基本容器調度策略有三種：

• spread 容器儘可能分布在不同的節點上
• binpack 容器儘可能分布在同一個節點上
• random 容器分布在隨機的節點上

Swarm集群的高可用配置很容易，以下圖為例：

manager配置在不同的AWS AZ中，通過領導選舉選出Primary manager。

多個節點分布在不同的AZ中，同時Consul／etcd／ZooKeeper也需要配成冗餘的。

特點

Docker Swarm的特點是配置和架構都很簡單，使用Docker原生的API，可以很好的融合Docker的生態系統。

Kubernetes

Kubernetes是Google開發的一套開源的容器應用管理系統，用於管理應用的部署，維護和擴張。利用Kubernetes能方便地管理跨機器運行容器化的應用。Kubernetes也是用Go語言開發的，在github上可以找到源代碼。

Kubernetes 源於谷歌公司的內部容器管理系統Borg，經過了多年的生產環境的歷煉，所以功能非常強大。

功能

Kubernetes主要提供一下的功能：

• 使用Docker對應用程序包裝(package)、實例化(instantiate)、運行(run)。
• 以集群的方式運行、管理跨機器的容器。
• 解決Docker跨機器容器之間的通訊問題。
• Kubernetes的自我修復機制使得容器集群總是運行在用戶期望的狀態。
• 應用的高可用和靠擴展
• 支持應用的在線升級（Rolling Update）
• 支持跨雲平台（IaaS）的部署

為了支持這些功能，Kubernetes做了做了很多的抽象概念，所以，剛開始使用Kubernetes，需要學習不少的新概念，包括：

• Pod
  Pod是Kubernetes的基本操作單元，把相關的一個或多個容器構成一個Pod，通常Pod里的容器運行相同的應用，或者是相關的應用。Pod包含的容器運行在同一個Minion(Host)上，看作一個統一管理單元，共享相同的volumes和network namespace/IP和Port空間。
• Job
  Job是一個生命周期比較短的應用，一般只會在出錯的情況下重啟，可以通過配置Job的並發和運行次數來擴展Job
• Service
  Service是一個生命周期比較長的應用，會在任何退出時重啟，可以通過配置Service的複製（Replica）來達到高擴展和高可用
• Recplica Controller
  Replication Controller確保任何時候Kubernetes集群中有指定數量的pod副本(replicas)在運行， 如果少於指定數量的pod副本(replicas)，Replication Controller會啟動新的Container，反之會殺死多餘的以保證數量不變。Replication Controller使用預先定義的pod模板創建pods，一旦創建成功，pod 模板和創建的pods沒有任何關聯，可以修改pod 模板而不會對已創建pods有任何影響，也可以直接更新通過Replication Controller創建的pods

以上是一些核心概念，除了這些，Kubernetes還提供其它一些概念，來支持應用程序的運維，包括：

• Label
  對系統中的對象通過Label的方式來管理
• Namespace

  對對象，資源分組，可以用於支持多租戶

• Config Map
  提供全局的配置數據存儲

總之，功能強大，系統概念繁多，比較複雜。

Kubernetes支持安裝UI的addon，來管理整個系統：

架構

下圖是Kubernetes的基本架構：

• Master
  Master定義了Kubernetes 集群Master/API Server的主要聲明，Client(Kubectl)調用Kubernetes API，管理Kubernetes主要構件Pods、Services、Minions、容器的入口。Master由API Server、Scheduler以及Registry等組成。
  Scheduler收集和分析當前Kubernetes集群中所有Minion節點的資源(內存、CPU)負載情況，然後依此分發新建的Pod到Kubernetes集群中可用的節點。由於一旦Minion節點的資源被分配給Pod，那這些資源就不能再分配給其他Pod， 除非這些Pod被刪除或者退出， 因此，Kubernetes需要分析集群中所有Minion的資源使用情況，保證分發的工作負載不會超出當前該Minion節點的可用資源範圍
• Minion
  Minion負責運行Pod，Service，Jobs， Minion通過Kubelet和Master通信。Proxy解決了外部網路能夠訪問跨機器集群中容器提供的應用服務。

• etcd
  負責集群的協調和服務發現

特點

Kubernetes提供了很多應用級別的管理能力，包括高可用可高擴展，當然為了支持這些功能，它的架構和概念都比較複雜，當然我覺得為了獲得這些功能，值！

Apache Mesos

Mesos是為軟體定義數據中心而生的操作系統，跨數據中心的資源在這個系統中被統一管理。Mesos的初衷並非管理容器，只是隨著容器的發展，Mesos加入了容器的功能。Mesos可以把不同機器的計算資源統一管理，就像同一個操作系統，用於運行分散式應用程序。

Mesos的起源於Google的數據中心資源管理系統Borg。你可以從WIRED雜誌的這篇文章中了解更多關於Borg起源的信息及它對Mesos影響。

功能

Mesos的主要功能包括：

• 高度的可擴展和高可用
• 可自定義的兩級調度
• 提供API進行應用的擴展
• 跨平台

下圖是Mesos的管理界面：

架構

Mesos的基本架構如下

• Master
  Master負責資源的統一協調和Slave的管理。 Master協調全部的Slave，並確定每個節點的可用資源，聚合計算跨節點的所有可用資源的報告，然後向註冊到Master的Framework（作為Master的客戶端）發出資源邀約。Mesos實現了兩級調度架構，它可以管理多種類型的應用程序。第一級調度是Master的守護進程，管理Mesos集群中所有節點上運行的Slave守護進程。集群由物理伺服器或虛擬伺服器組成，用於運行應用程序的任務，比如Hadoop和MPI作業。第二級調度由被稱作Framework的「組件」組成。
• Slave

  Salve運行執行器（Executor）進程來運行任務。

• Framework
  Framework包括調度器（Scheduler）和執行器（Executor）進程，其中每個節點上都會運行執行器。Mesos能和不同類型的Framework通信，每種Framework由相應的應用集群管理。
  Framework可以根據應用程序的需求，選擇接受或拒絕來自master的資源邀約。一旦接受邀約，Master即協調Framework和Slave，調度參與節點上任務，並在容器中執行，以使多種類型的任務
• ZooKeeper
  Zookeeper負責集群的協調，Master的領導選舉等

特點

Mesos相比Kubernetes和Swarm更為成熟，但是Mesos主要要解決的是操作系統級別的抽象，並非為了容器專門設計，如果用戶出了容器之外，還要集成其它的應用，例如Hadoop，Spark，Kafka等，Mesos更為合適。Mesos是一個更重量級的集群管理平台，功能更豐富，當然很多功能要基於各種Framework。

AWS ECS

ECS （Amazon EC2 Container Service ）是亞馬遜開發出的高度可擴展的高性能容器集群服務。在託管的 Amazon EC2 實例集群上輕鬆運行容器應用和服務。他最大的好處就是在雲上，不需要自己管理數據中心的機器和網路。

功能

ECS繼承了AWS服務的高擴展和高可用性，安全也可以得到保證。

在基本容器管理的基礎上，ECS使用Task和Service的概念來管理應用。

Task類似Docker Compose，使用一個JSON描述要運行的應用。Service是更高一層的抽象，包含多個task的運行實例，通過修改task實例的數量，可以控制服務的伸縮。同時Service可以保證指定數量的Task在運行，當出現錯誤的時候，重啟失敗的Task

架構

下圖是ECS的架構圖：

使用EC2，ELB，安全組等大家熟悉的AWS的概念，AWS用戶可以輕鬆管理你的容器集群。並且不需要付初基本資源以外的費用。

通過ECS agent可以是Container連接到ECS集群。ECS Agent使用Go開發，已開源。

我們並不清楚ECS的調度策略，但是AWS提供了一個例子，如果繼承第三方的調度策略。

通過Cloud Watch Log，我們可以很方便的對整個集群進行監控。

特點

如果你是一個AWS的重度用戶，ECS是個不錯的選擇，因為你可以是把你的容器集群運行在AWS的雲上，管理起來非常方便。

比較

這裡對幾個平台做一個簡單的比較：

總結

四個平台，Swarm是最輕量級的，功能也最簡單，適於有大量Docker實例環境的用戶。Kubernetes增加了很多應用級別的功能，適用於快速應用的部署和維護。Mesos最重，適用於已經有了相當的應用和容器混合的環境。ECS則推薦給AWS的用戶或者不希望自己管理數據中心的雲用戶。

相關鏈接

• 巔峰對決之Swarm、Kubernetes、Mesos
• Swarm v. Fleet v. Kubernetes v. Mesos
• Container Orchestration Tools: Compare Kubernetes vs Docker Swarm
• Container Orchestration Tools: Compare Kubernetes vs Mesos
• Compare Kubernetes vs ECS (Amazon EC2 Container Service)
• Evaluating Container Platforms at Scale
• Docker Swarm Wins Scaling Benchmark but Don』t Take That as Gospel

推薦閱讀：