Kubernetes，Mesos和Swarm：Rancher編排引擎的比較

【編者的話】Kubernetes是Google開源的容器集群管理系統，其提供應用部署、維護、 擴展機制等功能。Mesos是Apache下的開源分布式資源管理框架，它被稱為是分布式系統的內核。Mesos最初是由加州大學伯克利分校的AMPLab開發的，后在推ter得到廣泛使用。Swarm是Docker公司在2014年12月初新發布的容器管理工具。和Swarm一起發布的Docker管理工具還有Machine以及Compose。我們來看下Rancher對它們有什么評價

Rancher最新的版本在原有官方標準編排工具Cattle的基礎上，新增支持其他幾種常用的編排引擎。新增支持的編排引擎包括Swarm（Docker未來本地編排引擎）、Kubernetes和Mesos，它們都是Docker社區中最廣泛使用的編排系統，滿足用戶不同梯度的使用性和特性。盡管Docker是既定事實上的行業容器標準，但是在容器編排上還沒有絕對的贏家。這篇文章中我們我們主要介紹三種編排工具的特性，以及適應的場景。

目前Docker原生編排還處于初期階段，但是新的特性在快速迭代增加中。由于原生的編排工具是官方系統的一部分，因此它成為眾多開發者的默認首選編排工具，順理成章地最有可能成為最受社區歡迎支持的工具。Kubernetes是谷歌支持的容器編排工具，它在眾多容器編排工具中用的最廣泛的一個。最近，Mesos和Mesosphere（Marathon的開源版）把更多的精力放在服務管理，將更多的功能留給可插拔插件和應用程序管理。這樣的話，就使得應用最終容易容易定制部署，因為單個的程序更容易被更新，定制化。然而，這也意味著我們必須要修改一些設置來適配。Kubernetes更關注的是如何構建集群和在常見場景中用例的通用系統集成。

Docker Native Orchestration

基礎架構

Docker 1.12引擎中附帶了原生的編排工具，對獨立的Docker Swarm來說是一種替代。Docker本地集群（Swarm）包涵一系列節點（Docker進程/守護進程），他們同時管理集群及提供工作服務。你可以在容器中啟動工作進程也可以啟動管理進程維護集群的狀態。多管理模式保證了系統的高可用性，但是不推薦超過7個以上管理員用戶。內部通過 RAFT算法 實現主從的一致性。與所有一致性的算法是一樣的，多管理中心達到一致性的實現。實際上保持內部管理的一致也意味著Docker本地的編排不依賴外部資源，這樣也是集群的管理變得更加容易。

可用性

Docker本機使用單節點Docker的概念，并將它們擴展到Swarm。如果你使用最新的Docker版本，那么學習曲線還是相當平緩的。一旦你想添加已經在多節點運行的Docker到Swarm中，Swarm的設置是很簡單的：你只需在其中一個節點上調用docker swarm init，然后在任何其他你想添加的節點上調用docker swarm join即可。您也可以使用相同的Docker Compose模板和相同的Docker CLI命令集設計單一的Docker。

功能集

Docker本地可以使用與Docker Engine和Docker Compose相同的語法提供編排支持。你仍然可以鏈接到服務，創建卷，定義開放的端口號。所有的這些操作都適用于單個的節點，除了這些新增了兩個新的概念：服務和網絡。

Docker服務是您的節點上啟動的一組容器，并且保持這些批量的容器運行。如果其中一個容器停止，它將被自動替換掉。其中服務分類兩類：復制和全局。復制服務在集群中維護指定數量的容器，因為全局服務在每個集群節點上運行一個實例。要創建復制服務，請使用下面的命令：

docker service create          \

–name frontend              \

–replicas 5                 \

-network my-network         \

-p 80:80/tcp nginx:latest.

現在可以使用docker network create –driver overlay NETWORK_NAME創建命名為overlay的網絡。使用overlay網絡我們可以創建一個孤立、扁平、加密的虛擬網絡環境用來啟動容器。你可以使用約束和標簽來做一些非常基本的容器調度。使用約束可以向服務添加關聯，并且它將嘗試僅啟動具有特殊標簽的容器。

docker service create                        \

–name frontend                            \

–replicas 5                               \

-network my-network                       \

--constraint engine.labels.cloud==aws     \

--constraint node.role==manager           \

-p 80:80/tcp nginx:latest.

此外，你可以使用保留的CPU和保留的內存空間標志來定義服務的每個容器使用的資源，以便在swarm上啟動多個服務時，容器可以處理最小的資源競爭。

你可以使用以下命令進行初步的部署。這樣將會更新容器的鏡像，但是兩個容器之間有10s的間隔來更新兩個容器。然而，health-checks和自動回滾都不支持。

docker service update        \

–name frontend            \

–replicas 5               \

-network my-network       \

--update-delay 10s        \

--update-parallelism 2    \

-p 80:80/tcp nginx:other-version.

Docker使用卷驅動程序支持外部卷持久化，并且使用mount服務命令擴展器使用。執行以下代碼段將會將NFS裝入到您的容器中。請注意，這需要在Docker外部的底層主機上設置NFS。在沒有主機支持的情況下，其他對Amazon EBS卷或Google容器引擎卷驅動程序也能夠工作。此外，這個功能還沒有完善的文檔，可能需要需要在github的docker項目上創建issues得到交流回復。

--mount type=volume,src=/path/on/host,volume-driver=local,\

dst=/path/in/container,volume-opt=type=nfs,\

volume-opt=device=192.168.1.1:/your/nfs/path

Kubernetes

基礎架構

從概念上講，Kubernetes有點類似于Swarm，它使用一個帶有RAFT的管理器（主）節點來達成一致。然而，相似的地方也只有這么多了。 Kubernetes使用外部etcd集群為此目的。此外，你將需要Kubernetes外部的網絡層，這樣overlay 網絡就行編織法蘭絨外衣一樣。使用這些外部工具，您可以啟動Kubernetes主組件; API服務器，控制器管理器和調度程序。這些通常作為主節點上的Kubernetes pod運行。除了這些，你還需要在每個節點上運行kubelet和kubeproxy。如果需要的話，工作節點只運行Kubelet和Kubeproxy以及像一個包裝一樣作為網絡層提供者。

在這個設置中，kubelet將控制給定節點上的容器（或者pod）與主控制器上的控制器管理器。主節點上的調度器負責資源分配和平衡，并且將幫助在具有最多可用資源的工作節點上放置容器。 API控制器是您的本地kubectl CLI將向集群發出命令的地方。最后，kubeproxy用于為Kubernetes中定義的服務提供負載平衡和高可用性。

可用性

從頭開始設置Kubernetes是一個不平凡的努力，因為它需要設置etcd，網絡插件，DNS服務器和證書頒發機構。從頭開始設置Kubernetes的詳細信息可以在這里，但幸運的是Rancher為我們完成所有這些設置。我們在 前面的文章 中介紹了如何設置Kubernetes集群。

除了初始設置，Kubernetes仍然有一些陡峭的學習曲線，因為它使用自己的術語和概念。 Kubernetes使用資源類型，如Pods，部署，復制控制器，服務，守護進程集等來定義部署。這些概念不是Docker專門詞匯的一部分，因此您需要在開始創建第一個部署之前熟悉它們。此外，一些命名與Docker沖突。例如，Kubernetes服務不是Docker服務，也是概念上不同的（Docker服務更貼近地映射到Kubernetes世界中的Deployments）。此外，您使用kubectl而不是docker CLI與集群交互，并且必須使用Kubernetes配置文件而不是docker compose文件。

Kubernetes有這樣一套詳細的概念獨立于core Docker，這本身不是一件壞事。 Kubernetes提供比core Docker更豐富的功能集。然而，Docker將添加更多的功能來與Kubernetes競爭，具有不同的實現和不同或沖突的概念。這將幾乎肯定重復CoreOS / rkt情況，大部分社區在類似但競爭的解決方案。今天，Docker Swarm和Kubernetes定位于不同的使用場景（Kubernetes更適合于使用專用集群管理團隊的面向服務的架構的大型生產部署），但是隨著Docker 本地編排的成熟，它將遷移到這個空間。

功能集

Kubernetes的完整功能集太大，這篇文章不能涵蓋完整，但我們將介紹一些基本概念和一些有趣的區分。首先，Kubernetes使用Pods的概念作為基本單位，而不是單個容器。每個pod是一組容器（集合大小可以是一個），它們總是在同一節點上啟動，共享相同的卷并分配一個虛擬IP（VIP），以便可以在集群中尋址。單個pod的Kubernetes規范文件可能如下所示：

kind: Pod

metadata:

name: mywebservice

spec:

containers:

- name: web-1-10

image: nginx:1.10

ports:

- containerPort: 80

接下來是你的部署。這些松散地映射具體到什么服務是在Docker本地編排。您可以像Docker Native中的服務一樣擴展部署，部署將確保正在運行的請求數量的容器。重要的是注意部署僅類似于Docker本地中的復制服務，如Kubernetes使用守護程序集概念來支持其等效的全局調度服務。部署還支持使用HTTP或TCP可達性或自定義exec命令來確定容器/ pod是否正常的運行狀況檢查。部署還支持使用運行狀況檢查的自動回滾滾動部署，以確定每個pod部署是否成功。

kind: Deployment

metadata:

name: mywebservice-deployment

spec:

replicas: 2 # We want two pods for this deployment

template:

metadata:

  labels:

    app: mywebservice

spec:

  containers:

  - name: web-1-10

    image: nginx:1.10

    ports:

    - containerPort: 80

接下來你有Kubernetes服務，它為部署提供簡單的負載平衡。部署中的所有pod都將在服務進入和退出時注冊，服務也抽象出多個部署，因此如果您想回滾部署，您將使用相同的服務注冊兩個Kubernetes部署，然后逐個添加pod同時減少pods從其他。您甚至可以進行blue-green部署，您可以一次性將服務指向新的Kubernetes部署。最后，服務對于Kubernetes集群中的服務發現也很有用，集群中的所有服務都獲得VIP，并且作為docker鏈接樣式環境變量以及通過集成的DNS服務器暴露給集群中的所有pod。

除了基本服務，Kubernetes支持 作業 ， 調度計劃 作業和 Pet Sets 。作業創建一個或多個pod，并等待它們終止。作業確保指定數量的pod成功終止。例如，您可以開始一個作業，在最后一天開始處理1小時的商業智能數據。您將啟動一個包含前一天的24個pod的作業，一旦它們都運行完成，作業完成。作為名稱建議的計劃作業是在給定計劃上自動運行的作業。在我們的例子中，我們可能使我們的BI處理器是每日計劃的工作。作業非常適合向集群發出批處理工作負載，這些負載不總是需要啟動的服務，而是需要運行到完成然后清理的任務。

Kubernetes提供給基本服務的另一個擴展是Pet Sets。Pet Sets支持狀態服務工作負載，通常很難集中化。這包括數據庫和實時連接的應用程序。Pet Sets為集合中的每個“Pet”提供穩定的主機名。Pet就是索引。例如，pet5將獨立于pet3可尋址，并且如果第三Pet容器/ pod死掉，則它將在具有相同索引和主機名的新主機上重新啟動。

Pet Sets還提供使用持久卷的 穩定存儲 ，即如果pet1死亡并在另一個節點上重新啟動，它將獲得其重新安裝原始數據的卷。此外，您還可以使用NFS或其他網絡文件系統在容器之間共享卷，即使它們在不同的主機上啟動。這解決了從單主機到分布式Docker環境轉換時最有問題的問題之一。

Pet Sets還提供對等發現，通常可以發現其他服務（通過Docker鏈接等）。然而，發現服務中的其他容器是不可能的。這使得類似Cassandra和Zookeeper基于gossip協議的服務非常難以啟動。

最后，Pet Sets提供啟動和拆卸排序，這是持久、可擴展的服務，例如Cassandra。 Cassandra依賴一組種子節點，當您上下擴展服務時，必須確保種子節點是第一個啟動的節點和最后一個要刪除的節點。在撰寫本文時，Pet Sets是Kubernetes的一大特色，因為在沒有這種支持的情況下，持久的有狀態工作負載幾乎不可能在Docker的生產規模上運行。

Kubernetes還提供命名空間來隔離集群上的工作負載，保護管理和自動擴展支持。所有這些特性更意味著Kubernetes也支持大型，多樣化的工作負載，Docker Swarm目前還沒有準備就緒。

Marathon

基礎架構

大規模集群的另一個常見的編排設置是在Apache Mesos之上運行Marathon。 Mesos是一個開源集群管理系統，支持各種工作負載數組。 Mesos由在群集中的每個主機上運行的Mesos代理組成，它向主機報告其可用資源。可以有一個或多個Mesos主機使用Zookeeper集群進行協調。在任何給定時間，主節點之一使用主選舉過程是活動的。主服務器可以向任何Mesos代理發出任務，并報告這些任務的狀態。雖然您可以通過API發出任務，但正常的方法是在Mesos之上使用一個框架。 Marathon是一個這樣的框架，它為運行Docker容器（以及本地Mesos容器）提供支持。

可用性

與Swarm相比，Marathon有一個相當陡峭的學習曲線，因為它不與Docker共用大部分概念和術語。然而，馬拉松并不復雜，因此比Kubernetes更容易學習。然而，管理Marathon部署的復雜性來自于它是分層在Mesos，因此有兩層工具要管理。此外，Marathon的一些更高級功能（如負載平衡）僅作為在Marathon之上運行的附加框架提供。某些功能（如身份驗證）只有在DC / OS上運行Marathon時才可用，而后者又在Mesos上運行 - 為堆棧添加另一層抽象。

功能集

要在Marathon中定義服務，您需要使用其內部JSON格式，如下所示。一個簡單的定義，如下面的一個將創建一個服務，每個運行nginx容器的兩個實例。

{

"id": "MyService"

"instances": 2,

"container": {

"type": "DOCKER",

"docker": {

  "network": "BRIDGE",

  "image": "nginx:latest"

}

}

}

以上定義稍微更完整的版本如下所示，我們現在添加端口映射和health check。在端口映射中，我們指定一個容器端口，這是docker容器公開的端口。主機端口定義主機公共接口上的哪個端口映射到容器端口。如果為主機端口指定0，則在運行時分配隨機端口。類似地，我們可以可選地指定服務端口。服務端口用于服務發現和負載平衡，如本節后面所述。使用健康檢查，我們現在可以執行滾動（默認）和 blue-green 部署。

{

"id": "MyService"

"instances": 2,

"container": {

"type": "DOCKER",

"docker": {

  "network": "BRIDGE",

  "image": "nginx:latest"

  "portMappings": [

    { "containerPort": 8080, "hostPort": 0, "servicePort": 9000, "protocol": "tcp" },

  ]

}

},

"healthChecks": [

{

  "protocol": "HTTP",

  "portIndex": 0,

  "path": "/",

  "gracePeriodSeconds": 5,

  "intervalSeconds": 20,

  "maxConsecutiveFailures": 3

}

]

}

除了單一服務之外，您還可以定義Marathon應用程序組，使用嵌套樹結構的服務。在組中定義應用程序的好處是能夠將整個組縮放在一起。這在微服務堆棧中非常有用，其中調整單個服務可能是困難的。到目前為止，擴展假設所有服務將以相同的速率擴展，因此如果您需要一個服務的“n”個實例，您將獲得所有服務的“n”個實例。

{

"id": "/product",

"groups": [

{

  "id": "/product/database",

  "apps": [

     { "id": "/product/mongo", ... },

     { "id": "/product/mysql", ... }

   ]

},{

  "id": "/product/service",

  "dependencies": ["/product/database"],

  "apps": [

     { "id": "/product/rails-app", ... },

     { "id": "/product/play-app", ... }

  ]

}

]

}

除了能夠定義基本服務之外，Marathon還可以基于指定約束來執行容器的調度，包括指定服務的每個實例必須在不同的物理主機“約束”上：[[“hostname”, “UNIQUE”]]。您可以使用cpus和mem標記來指定該容器的資源利用率。每個Mesos代理報告其總資源可用性，因此調度程序可以以智能方式在主機上放置工作負載。

默認情況下，Mesos依賴于傳統的Docker端口映射和外部服務發現和負載平衡機制。但是，最近的測試功能添加了對使用Mesos DNS的DNS服務發現或使用Marathon LB的負載平衡的支持。 Mesos DNS 是一個在 Mesos LB 之上運行的應用程序，它查詢Mesos API以獲取所有正在運行的任務和應用程序的列表。然后，它為運行這些任務的節點創建DNS記錄。然后，所有Mesos代理手動更新，以使用Mesos DNS服務作為其主DNS服務器。 Mesos DNS使用用于向主機注冊Mesos代理的主機名或IP地址;并且端口映射可以查詢為SRV記錄。由于Marathon DNS在代理主機名上工作，并且主機網絡端口必須被公開，因此不能發生沖突。 Mesos DNS確實提供了一種方法來為狀態負載持續引用單個容器，例如我們將能夠使用Kubernetes寵物集。此外，與群集中任何容器上可尋址Kubernetes VIP不同，我們必須手動將/etc/resolve.conf更新到Mesos DNS服務器集，并在DNS服務器更改時更新配置。 Marathon-lb 使用馬拉松賽事總線跟蹤所有服務的啟動和撤銷。然后，它在代理節點上啟動HAProxy實例，以將流量中繼到必需的服務節點。

Marathon還對 持久性卷 以及 外部持久卷 提供測試支持。然而，這兩個特征都處于非常原始的狀態。持久卷只在容器重新啟動的單個節點上持久化，但是如果刪除使用它們的應用程序，則會刪除卷，但磁盤上的實際數據不會被刪除，必須手動刪除。外部卷需要DC / OS，并且當前只允許您的服務擴展到單實例。

最終裁決

今天我們看了Docker容器編排的三個選項：Docker Native（Swarm），Kubernetes和Mesos / Marathon。很難選擇一個系統來推薦，因為最好的系統高度依賴于你的用例，規模和歷史。此外，所有三個系統都在大量開發，一些涵蓋的功能是測試版，可能會很快更改，刪除或替換。

Docker Native給你提供了最快的升級，很少甚至沒有供應商的封閉超出了對Docker的依賴。對Docker的依賴不是一個大問題，因為它已經成為了實際上容器標準。鑒于在編排戰爭中缺乏明確的贏家，而且Docker本機是最靈活的方法，因此它是簡單的web/stateless應用程序的不錯選擇。但是，Docker Native目前還只是一個架子，如果你需要得到復雜的，大規模的應用程序到生產，你需要選擇一個Mesos / Marathon或Kubernetes。

在Mesos / Marathon和Kubernetes之間也不是一個容易的選擇，因為兩者都有自己的優點和缺點。 Kubernetes肯定是更豐富和成熟的兩個，但它也是一個非常有見地的軟件。我們認為很多這些意見是有意義的，但Kubernetes沒有馬拉松的靈活性。這是有道理的，當你考慮非Docker，非容器化的應用程序，可以運行在Mesos除了Marathon（例如Hadoop集群）的豐富的歷史。如果你正在做一個綠色領域實施，也沒有強烈的意見，如何布局集群，或你的意見同意谷歌，那么Kubernetes是一個更好的選擇。相反，如果你有大的，復雜的遺留工作負載，將逐漸轉移到容器，那么Mesos / Marathon是要走的路。

另一個問題是規模：Kubernetes已經測試了數千個節點，而Mesos已經測試了成千上萬的節點。如果您正在啟動具有數萬個節點的集群，則需要使用Mesos來獲得底層基礎架構的可擴展性 - 但請注意，將高級功能（例如負載平衡）擴展到該范圍仍將保留。然而，在那個規模，很少（如果有的話）現成的解決方案工作作為廣告，沒有仔細調整和猴子修補。

 

 

來自：http://dockone.io/article/1882