容器化和微服務是當前最熱話題，不久之前，筆者（據說因爲現在都不用筆了，“筆者”的稱謂已經不合適了，因爲輸入用鍵盤，叫“鍵人”更爲合適）參加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。
Mesos的擴展性非常好，最大支持50000節點，如果對擴展性要求非常高的話麼，Mesos是最佳選擇。
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 | Kubernetes | Mesos | ECS | |
| 基本功能 | Docker原生的集羣管理工具 | 開源的容器集羣工具，提供應用級別的部署，維護和擴張功能 | 基於數據中心的操作系統 | 基於雲的高可用，高擴展容器集羣 |
| 高層次抽象 | 無 | Pod |
無 | Task Service |
| 應用擴展性 | 無 | 支持 | Framework 支持 | 支持 |
| 應用高可用性 | 無 | 支持 | Framework 支持 | 支持 |
| 集羣協調和服務發現 | etcd |
etcd | ZooKeeper | ／ |
| 調度策略（Schedule） | 內置，可擴展 | 內置 | 兩級別，可擴展 | 可擴展 |
| 監控 | Logging Driver | Heapter，ELK Addon | 內置 | CloudWatch |
| 用戶界面 | CLI |
CLI API UI |
API UI |
CLI |
| 開發語言 | Go | Go | Java | NA |
| 開源 | 是 | 是 | 是 | 否 |
| 最大支持管理節點數 | 官方1000 |
官方1000 |
10000 | ／ |
總結
四個平臺，Swarm是最輕量級的，功能也最簡單，適於有大量Docker實例環境的用戶。Kubernetes增加了很多應用級別的功能，適用於快速應用的部署和維護。Mesos最重，適用於已經有了相當的應用和容器混合的環境。ECS則推薦給AWS的用戶或者不希望自己管理數據中心的雲用戶。