Swarm、Fleet、Kubernetes、Mesos - 編排工具的對比分析
大部分軟體系統是随時間演進的，新舊功能會交替，不斷變化的使用者需求意味着一個高效的系統必須能夠迅速擴充或收縮資源。為了達到接近零當機的需求，一個單獨的資料中心需要自動地将故障轉移到預設的備份系統。
在此之上，一些大型企業經常會運作多個這樣的系統或是偶爾需要運作一些獨立于主系統的任務，比如資料挖掘，但是又需要更多資源而且需要和現存系統互動。
當使用多個資源時，重要的是確定他們得到有效地使用，而不是被閑置，但還可以應對需求高峰。成本效益與迅速擴充的規模之前的權衡是困難的任務，但是可以用各種方式加以處理。
所有這一切都意味着一個非凡系統的運作充滿了各種管理任務、挑戰以及不應低估的複雜性。很快在個體層面一個接一個地修補和更新某個機器将變為不可能，他們必須同等對待。當一台機器發生問題時，它應該被摧毀并更換，而不是調養修複後再上線。
目前有各種工具和解決方案能夠幫助解決這些挑戰，這裡主要集中講解幾個編排工具，這些工具能幫助我們以叢集方式在主機上啟動容器，并能夠彼此連接配接，同時也考慮到了擴充性和自動故障轉移的重要特性。
Swarm
Swarm的基本架構很簡單：每個主機運作一個Swarm代理，一個主機運作Swarm管理器（在測試的叢集中，這個主機也可以運作代理），這個管理器負責主機上容器的編排和排程。Swarm能以高可用性模式（etcd、Consul 或ZooKeeper 中任何一個都可以用來将故障轉移給後備管理器處理）運作。當有新主機加入到叢集，有幾種不同的方式來發現新加的主機，在Swarm中也就是discovery。預設情況下使用的是token，也就是在Docker Hub上會儲存一個主機位址的清單。
Fleet
每個機器運作一個引擎和一個代理，任何時候在叢集中隻激活一個引擎，但是所有代理會一直運作，Systemd單元檔案被送出給引擎，然後在 least-loaded機器上排程任務，單元檔案會簡單運作一個容器，代理會啟動單元和報告狀态，Etcd用來激活機器間的通訊以及存儲叢集和單元的狀态。
這個架構用來設計容錯的，如果一個機器當機了，這個機器上的所有單元會在新的主機上被重新啟動。
Fleet支援各種排程提示與限制。在最基本的層面，單元的排程可以是全局的：一個執行個體将在所有機器上運作，或者作為一個單獨的單元運作在一台機器上。全局排程對于如日志和監控容器任務非常實用。支援各種關聯類型限制，是以，例如規定在應用伺服器上運作健康檢查的容器。中繼資料也可以連接配接到主機用于排程，是以你可以讓你的容器在某一區域或某些硬體裝置上運作。
由于Fleet是基于systemd的，它也支援socket activation概念；容器可以綁定到一個給定端口的連接配接響應上。這樣做的主要優點是程序可以即時建立而不是閑置等待某些任務。有可能涉及到sockets管理的其他好處，如容器重新開機的消息不丢失。
Kubernetes
Pods – Pods是容器一起部署與排程的群體。Pods與其他系統的單一容器相比，它組成了Kubernetes中排程的原子單元。Pod通常會包括1-5個一起提供服務的容器。除了這些使用者容器，Kubernetes還會運作其他容器來提供日志和監控服務。在Kubernetes中Pods壽命短暫;随着系統的進化他們不斷地建構和銷毀。
Flat Networking Space – Kubernetes的網絡是跟預設的Docker網絡不同。在預設Docker網絡中， 容器存在于一個私有子網絡中，它需要賺翻主機上的端口或者使用代理才能與其他主機上的容器通訊。在Kubernetes，pod中的容器會分享一個IP位址，但是該位址空間跟所有的pods是"平"的，這意味着所有pods不用任何網絡位址轉換（NAT）就可以互相通訊。這就使得多主機群集更容易管理，不支援連結的代價使得建立單台主機（更準确地說是單個pod）網絡更為棘手。由于在同一個pod中的容器共享一個IP，它們可以通過使用本地主機位址端口進行通信（這并不意味着你需要協調pod内的端口使用）。
Labels – Labels是附在Kubernetes對象（主要是pods）上用于描述對象的識别特征的鍵值對，例如版本：開發與層級：前端。通常Labels不是唯一的；它們用來識别容器組。Labels選擇器可以用來識别對象或對象組，例如設定所有在前端層的pods與環境設定為production。使用Labels可以很容易地處理分組任務，例如配置設定pods到負載均衡組或者在組織之間移動pods。
Services – Services是通過名稱來定位的穩定的節點。Services使用label選擇器來連接配接pods，比如"緩存"Service可以連接配接到辨別為label選擇器"type"為"redis"的某些"redis"pods。該service将在這些pods之間自動循環地請求。以這種方式，Services可用于連接配接一個系統各部件。使用Services會提供一個抽象層，這意味着應用程式并不需要知道他們調用的service的内部細節，例如pods内部運作的應用程式隻需要知道調用的資料庫service的名稱和接口，它不必關心有多少pods組成了那個資料庫，或者上次它調用了哪個pod。 Kubernetes會為叢集建立一個DNS伺服器，用于監視新的services并允許他們在應用程式代碼和配置檔案中按名稱定位。它也可以設定services不指向pods而是指向其他已經存在的services，比如外部API或資料庫。
Replication Controllers - Replication controllers是Kubernetes執行個體化pods的正常方式（通常情況下，在Kubernetes中不使用Docker CLI）。它們為service來控制和監視運作的pods數量（稱為replicas）。例如，一個replication controller可以負責維持5個Redis的pods的運作。如果一個失敗，它會立即啟動一個新的。如果replicas的數量減少，它會停止多餘的pods。雖然使用Replication Controllers來執行個體化所有pods會增加一層額外的配置，但是它顯著提高容錯性和可靠性。
Mesos 和 Marathon
Apache Mesos始于加州大學伯克利分校的一個項目，用來驅動Twitter的底層基礎架構，并且成為許多大公司如eBay和Airbnb的重要工具。後來Mesosphere（共同創辦人之一：Ben Hindman - Mesos原始開發人員 ）做了很多持續性的Mesos開發和支援工具（如Marathon）。
Mesos的體系結構是圍繞高可用性和彈性而設計的。在一個Mesos群集的主要組成部分是：
Mesos Agent Nodes - 負責實際的運作任務。所有代理向Master送出其可用資源。通常會有數十到上千的節點。
Mesos Master - 負責給Agents發送任務。它維護一個現有資源的清單并且将此"提供"給Frameworks。Master基于配置設定政策來決定提供多少資源。通常會有2個或4個備用Master來接替故障的Master。
ZooKeeper - 用于選擇和查找目前Master位址。通常情況下會運作3個或5個ZooKeeper執行個體以確定可用性和故障處理。
Frameworks - 與Master協調排程任務到Agent節點。Frameworks由兩部分組成：executor程序會運作代理并維護運作的任務以及那些已注冊的寄存器，還可以選擇使用那些基于來自主機提供的資源。Mesos叢集為不同種類的任務可以運作多種Frameworks。使用者希望與frameworks互動來送出任務而不是和Mesos互動。
上圖中我們可以看到Mesos叢集使用framework作為排程器。Marathon排程器使用ZooKeeper來定位目前要送出任務的Mesos master。無論是Marathon排程器還是Mesos master都有備用以便目前master不可用的時候使用。
通常情況下，ZooKeeper，作為Mesos master以及備用，它會運作在同一台主機上。在一個小的叢集中，這些主機也可以運作代理，但是更大的叢集做這些就不可行，因為它們需要與master通信。Marathon也可以運作在同一個主機上，或者運作在存在于網絡邊界的獨立主機上，而且還可以為用戶端形成接入點，進而保持用戶端與Mesos叢集分離。
結論
編排、叢集以及管理容器顯然有多種選擇。話雖如此，但這些選擇一般都是高度分化的。在編排方面，我們可以說：
Swarm具有使用标準Docker接口的優勢（及劣勢）。雖然這樣使得它與現有的工作流程互動起來簡單易用，但也可能對于支援更為複雜的定義在定制接口的排程變得更加困難。
Fleet是底層級的而且相當簡單的編排層，它被于運作更進階别的編排工具，例如Kubernetes或者自定義系統。
Kubernetes是帶有服務發現和複制的編排工具。它可能需要重新設計一些現有的應用程式，但是正确地使用可以提供一個可容錯和可擴充的系統。
Mesos是一種底層級、久經沙場的排程器，對于容器的編排，它支援多種frameworks，包括Marathon、Kubernetes、和Swarm。在寫這篇文章的時候，Kubernetes和Mesos比Swarm開發的更多以及更為穩定。在規模上，隻有Mesos已經證明了支援成百上千個節點的大型系統。但是，對于小的叢集比方說，還不到十幾個節點的叢集，用Mesos可能過于複雜。