轉載自:http://dockone.io/article/1138  感謝作者和編者的分享

【編者的話】這篇文章對比了三大主流排程框架：Swarm、Kubernetes和Mesos。文章不僅從理論上討論了各個框架的優缺點，還從兩個實際的案例出發，分析了每個框架具體使用方法。


這篇文章對比了三大主流排程框架：Docker Swarm、Google Kubernetes和Apache Mesos（基於Marathon框架）。在解釋了排程和容器的基本概念後，文章探討了每個框架的特點，並從以下兩個用例來對比他們：一個只使用了兩個容器的網站應用，和一個能具有可擴充套件性的投票應用。

什麼是排程（scheduling）？什麼是容器（container）？

排程

一個叢集排程工具有多個目的：使得叢集的資源被高效利用，支援使用者提供的配置約束（placement constraint），能夠迅速排程應用以此保證它們不會處於待定狀態（pending state），有一定程度的“公平”（fairness），具有一定的魯棒性和可用性。為了達到這些目的，在一篇關於Omega（一個由Google開發的，針對大型計算叢集的可擴充套件排程框架）的白皮書中，提到了三個主要的排程架構[48]：

Schematic overview of scheduling architectures, © Google, Inc. [48]

一體式排程（Monolithic scheduling）

一體式排程框架由單一的排程代理（scheduling agent）組成，它負責處理所有的請求，這種框架通常應用於高效能運算。一體式框架通常實現了一個單一的演算法來處理所有的作業（job），因此根據作業的型別來執行不同的排程邏輯是困難的。

Apache Hadoop YARN[55]是一個非常流行的架構，儘管它將許多排程功能都分發到每一個應用模組中，但它依然是一體式的排程架構，因為，實際上，所有的資源請求都會被髮送到一個單一的全域性排程模組。

兩級排程（Two-level scheduling）

兩級排程框架會利用一箇中央協調器（central coordinator）來動態地決定各個排程模組可以呼叫多少資源。這項技術被應用於Mesos[50]和Hadoop-on-Demand（現在被YARN取代了）。

在這類架構裡，分配器會將給定的資源一次性分配個一個框架，因此避免了資源使用的衝突，並且通過控制資源分配的順序和大小來實現一種相對的資源公平分配。然而，一個資源每次只能被一個框架使用，因此併發控制被稱之為悲觀的（pessimistic），這種控制策略是不易於出錯的（less error-prone），但是相對於將一個資源同時分配個多個框架的樂觀併發式控制來說，速度是更慢的。

共享狀態排程（Shared-state scheduling）

Omega 賦予了每一個排程器（scheduler）對整個叢集的全部訪問許可權，也就是說排程器們可以自由地競爭。因為所有的資源分配都發生在各個排程器中，所以也就沒有了中央資源分配器。也就是說，沒有了中央策略引擎，每一個排程器能夠自己做決定。

通過支援獨立的排程器實現和公佈整個資源分配的狀況，Omega不僅支援擴充套件多個排程器，還能夠支援它們自己的排程策略[54]

哪一個才是最好的排程架構？

世界上並不存在一個通用的唯一方案來解決叢集計算的所有問題，因此不同的公司為了適應需求，各自開發了不同的產品。Google（Omege和Kubernetes的主要貢獻者）假設開發者們會遵守關於作業優先順序的規則，因此Google認為架構應該把控制權交給開發者；而Yahoo！（YARN的主要貢獻者）更推崇強制容量、公平和截止時間的框架。

容器革命（The container revolution）

容器是虛擬機器的一種替代品，它能夠幫助開發者構建、遷移、部署和例項化應用[3]。一個容器是程序的集合，這些程序獨立於包含有程序依賴的機器。

各個容器儘管共享了一個作業系統例項，但是它們獨立執行，互不影響。容器並不需要一個完整的作業系統，這個特性使得它們比虛擬機器更加輕量。

因為容器能夠在數秒內啟動（比虛擬機器快多了），因此容器僅分配了少量的資源（少於2GB的RAM）並且能通過擴充套件來滿足應用的需求。容器經常被應用於微服務（microservices），每一容器代表一個服務，這些服務通過網路來進行互聯。這種架構使得每一個模組都能夠被獨立地部署和擴充套件。

資源的數量和所期望的容器生命週期是普通排程器和容器排程器的主要區別。傳統叢集設計，比如說Hadoop，更關注於執行大規模作業[55]，然而容器叢集則會執行幾十個小的例項來解決問題，這些例項需要被組織化和網路化，以此來優化共享資料和計算的能力。

Docker

Docker是一個主流容器管理工具，它是第一個基於Linux容器（LXC）的[2]，但是現在被runC[46]所取代了（runC是是一個由Open Containers Initiative開發的CLI工具，它能夠建立和執行容器[36]）。Docker容器支援分層的檔案系統，因此它能夠和宿主機共享系統核心。這個特性意味著即便一個Docker映象基於一個1GB的作業系統，在同一個主機上執行10個容器例項並不需要消耗10GB的空間，相比之下，每一臺虛擬機器都需要一個完整的1GB作業系統。

Virtual machines architecture compared to containers, © Docker Inc. [23]

Docker的映象可以理解為一個作業系統的快照。如果你想要建立一個新的映象，你需要啟動一個基礎映象，然後做一些修改，最後提交修改，形成新的映象。這些映象能夠釋出在私有或者公有的庫上[10]供其他開發者使用，開發者只需要將映象pull下來即可。

使用映象可以非常方便的建立作業系統的快照，並且使用它們來建立新的容器，這些功能非常的輕量和易用，這些都是Docer CLI和商業模式的核心。[12]

容器包含了所有執行所需要的東西（程式碼，執行時，系統工具，庫），因此Docker給予開發者一個輕量的，穩定的環境來快速地進行建立和執行作業。

容器排程簡介（Description of container schedulers）

容器排程工具的主要任務就是負責在最合適的主機上啟動容器，並且將它們關聯起來。它必須能夠通過自動的故障轉移（fail-overs）來處理錯誤，並且當一個例項不足以處理/計算資料時，它能夠擴充套件容器來解決問題。

這篇文章比較了三個主流容器排程框架：Docker Swarm [13], Apache Mesos (running the Marathon framework) [50] and Google Kubernetes [31]。在這一節，將會討論各個框架的設計和特點。

Docker Swarm

Docker Swarm是一個由Docker開發的排程框架。由Docker自身開發的好處之一就是標準Docker API的使用[17]。Swarm的架構由兩部分組成：

Docker Swarm architecture, ©Alexandre Beslic (Docker Inc.) [14]
其中一個機器運行了一個Swarm的映象（就像執行其他Docker映象一樣），它負責排程容器[4]，在圖片上鯨魚代表這個機器。Swarm使用了和Docker標準API一致的API，這意味著在Swarm上執行一個容器和在單一主機上執行容器使用相同的命令。儘管有新的flags可用，但是開發者在使用Swarm的同時並不需要改變他的工作流程。

Swarm由多個代理（agent）組成，把這些代理稱之為節點（node）。這些節點就是主機，這些主機在啟動Docker daemon的時候就會開啟相應的埠，以此支援Docker遠端API[5]。其中三個節點顯示在了圖上。這些機器會根據Swarm排程器分配給它們的任務，拉取和執行不同的映象。

當啟動Docker daemon時，每一個節點都能夠被貼上一些標籤（label），這些標籤以鍵值對的形式存在，通過標籤就能夠給予每個節點對應的細節資訊。當執行一個新的容器時，這些標籤就能夠被用來過濾叢集，具體的細節在後面的部分詳談。

策略(Strategies)

Swarm採用了三個策略（比如說，策略可以是如何選擇一個節點來執行容器）[22]:

策略名：節點選擇

• spread：最少的容器，並且忽視它們的狀態
• binpack：最擁擠（比如說，擁有最少數量的CPU/RAM）
• random：隨機選擇

如果多個節點被選中，排程器會從中隨機選擇一個。在啟動管理器（manager）時，策略需要被定義好，否則“spread”策略會被預設使用。

過濾器（Filters）

為了在節點子集中排程容器，Swarm提供了兩個節點過濾器（constraint和health），還有三個容器配置過濾器（affinity，dependency和port）。

約束過濾器（Constraint filter）

每一個節點都關聯有鍵值對。為了找都某一個關聯多個鍵值對的節點，你需要在docker daemon啟動的時候，輸入一系列的引數選項。當你在實際的生產環境中執行容器時，你可以指定約束來完成查詢，比如說一個容器只會在帶有環境變數key=prod的節點上執行。如果沒有節點滿足要求，這個容器將不會執行。

一系列的標準約束已經被設定，比如說節點的作業系統，在啟動節點時，使用者並不需要設定它們。

健康過濾器（Health filter）

健康過濾器用來防止排程不健康的節點。在翻看了Swarm的原始碼後，只有少量關於這個概念的資訊是可用的。

吸引力過濾器（Affinity filter）

吸引力過濾器是為了在執行一個新的容器時，建立“吸引力”。涉及到容器、映象和標籤的吸引力存在有三類。

對容器來說，當你想要執行一個新的容器時，你只需要指定你想要連結的容器的名字（或者容器的ID），然後這些容器就會互相連結。如果其中一個容器停止運行了，剩下的容器都會停止執行。

映象吸引力將會把想要執行的容器排程到已經擁有該映象的節點上。

標籤吸引力會和容器的標籤一起工作。如果想要將某一個新的容器緊挨著指定的容器，使用者只需要指定一個key為container，value為<container_name>的吸引力就可以了。

吸引力和約束的語法接受否定和軟強制（soft enforcement），即便容器不可能滿足所有的需求。[18]

依賴過濾器（Dependency filter）

依賴過濾器能夠用來執行一個依賴於其他容器的容器。依賴意味著和其他容器共享磁碟卷，或者是連結到其他容器，亦或者和其他容器在同一個網路棧上。

埠過濾器（Port filter）

如果你想要在具有特定開發埠的節點上執行容器，你就可以使用埠過濾器了。如果叢集中沒有任何一個節點該埠可用的話，系統就會給出一個錯誤的提示資訊。

Apache Mesos & Mesosphere Marathon

Mesos的目的就是建立一個高效可擴充套件的系統，並且這個系統能夠支援很多各種各樣的框架，不管是現在的還是未來的框架，它都能支援。這也是現今一個比較大的問題：類似Hadoop和MPI這些框架都是獨立開的，這導致想要在框架之間做一些細粒度的分享是不可能的。[35]

因此Mesos的提出就是為了在底部新增一個輕量的資源共享層（resource-sharing layer），這個層使得各個框架能夠適用一個統一的介面來訪問叢集資源。Mesos並不負責排程而是負責委派授權，畢竟很多框架都已經實現了複雜的排程。

取決於使用者想要在叢集上執行的作業型別，共有四種類型的框架可供使用[52]。其中有一些支援原生的Docker，比如說Marathon[39]。Docker容器的支援自從Mesos 0.20.0就已經被加入到Mesos中了[51]。

我們接下來將會重點關注如何在讓Mesos和Marathon一起工作，畢竟Marathon主要是由Mesosphere維護[41]，並且提供了很多關於排程的功能，比如說約束（constraints）[38]，健康檢查（health checks）[40]，服務發現（service discovery）和負載均衡（load balancing）[42]。

Apache Mesos architecture using Marathon, © Adrian Mouat [49]

我們可以從圖上看到，叢集中一共出現了4個模組。ZooKeeper幫助Marathon查詢Mesos master的地址[53]，同時它具有多個例項可用，以此應付故障的發生。Marathon負責啟動，監控，擴充套件容器。Mesos maser則給節點分配任務，同時如果某一個節點有空閒的CPU/RAM，它就會通知Marathon。Mesos slave執行容器，並且報告當前可用的資源。

約束（Constraints）

約束使得操作人員能夠操控應用在哪些節點上執行，它主要由三個部分組成：一個欄位名（field name）（可以是slavve的hostname或者任何Mesos slave屬性），一個操作符和一個可選的值。5個操作符如下：

操作符：角色（role）

• UNIQUE：使得屬性唯一，比如說越蘇[“hostname”,”UNIQUE”]使得每個host上只有一個應用在執行。
• CLUSTER：使得執行應用的slaves必須共享同一個特定屬性。比如說約束 [“rack id”, “CLUSTER”, “rack-1”] 強制應用必須執行在rack-1上，或者處於掛起狀態知道rack-1有了空餘的CPU/RAM。
• GROUP_BY：根據某個特性的屬性，將應用平均分配到節點上，比如說特定的host或者rack。
• LIKE：使得應用只執行在擁有特定屬性的slaves上。儘管只有CLUSTER可用，但由於引數是一個正則表示式，因此很多的值都能夠被匹配到。
• UNLIKE：和LIKE相反。

健康檢查（Health checks）

健康檢查是應用依賴的，需要被手動實現。這是因為只有開發者知道他們自己的應用如何判斷健康狀態。（這是一個Swarm和Mesos之間的不同點）

Mesos提供了很多選項來宣告每個健康檢查之間需要等待多少秒，或者多少次連續的健康檢查失敗後，這個不健康的任務需要被終結。

服務發現和負載均衡（Service discovery and load balancing）

為了能夠傳送資料到正在執行的應用，我們需要服務發現。Apache Mesos提供了基於DNS的服務發現，稱之為Mesos-DNS[44]，它能夠在多個框架（不僅僅是Marathon）組成的叢集中很好的工作。

如果一個叢集只由執行容器的節點組成，Marathon足以承當起管理的任務。在這種情況下，主機可以執行一個TCP的代理，將靜態服務埠的連線轉發到獨立的應用例項上。Marathon確保所有動態分配的服務埠都是唯一的，這種方式比手動來做好的多，畢竟多個擁有同樣映象的容器需要同一個埠，而這些容器可以執行在同一個主機上。

Marathon提供了兩個TCP/HTTP代理。一個簡單的shell指令碼[37]還有一個更復雜的指令碼，稱之為marathon-ld，它擁有更多的功能[43]。

Google Kubernetes

Kubernetes是一個Docker容器的編排系統，它使用label和pod的概念來將容器換分為邏輯單元。Pods是同地協作（co-located）容器的集合，這些容器被共同部署和排程，形成了一個服務[28]，這是Kubernetes和其他兩個框架的主要區別。相比於基於相似度的容器排程方式（就像Swarm和Mesos），這個方法簡化了對叢集的管理.

Kubernetes排程器的任務就是尋找那些PodSpec.NodeName為空的pods，然後通過對它們賦值來排程對應叢集中的容器[32]。相比於Swarm和Mesos，Kubernetes允許開發者通過定義PodSpec.NodeName來繞過排程器[29]。排程器使用謂詞（predicates）[29]和優先順序（priorites）[30]來決定一個pod應該執行在哪一個節點上。通過使用一個新的排程策略配置可以覆蓋掉這些引數的預設值[33]。

命令列引數plicy-config-file可以指定一個JSON檔案（見附錄A）來描述哪些predicates和priorities在啟動Kubernetes時會被使用，通過這個引數，排程就能夠使用管理者定義的策略了。

Kubernetes architecture (containers in grey, pods in color), © Google Inc. [31]

謂詞（Predicates）

謂詞是強制性的規則，它能夠用來排程叢集上一個新的pod。如果沒有任何機器滿足該謂詞，則該pod會處於掛起狀態，知道有機器能夠滿足條件。可用的謂詞如下所示：

• Predicate：節點的需求
• PodFitPorts：沒有任何埠衝突
• PodFitsResurce：有足夠的資源執行pod
• NoDiskConflict：有足夠的空間來滿足pod和連結的資料卷
• MatchNodeSelector：能夠匹配pod中的選擇器查詢引數。
• HostName：能夠匹配pod中的host引數

優先順序（Priorities）

如果排程器發現有多個機器滿足謂詞的條件，那麼優先順序就可以用來判別哪一個才是最適合執行pod的機器。優先順序是一個鍵值對，key表示優先順序的名字，value就是該優先順序的權重。可用的優先順序如下：

• Priority：尋找最佳節點
• LeastRequestdPriority：計算pods需要的CPU和記憶體在當前節點可用資源的百分比，具有最小百分比的節點就是最優的。
• BalanceResourceAllocation：擁有類似記憶體和CPU使用的節點。
• ServicesSpreadingPriority：優先選擇擁有不同pods的節點。
• EqualPriority：給所有叢集的節點同樣的優先順序，僅僅是為了做測試。

結論

以上三種框架提供了不同的功能和歸來來自定義排程器的邏輯。從這節來看，顯而易見，由於Swarm的原生API，Swarm是三個中最容易使用的。

以Docker的方式來執行容器[15]意味著一個容器是短暫存在的，並且每一個容器只執行一個程序。根據這條原則，多個容器提供一個服務或者代表一個應用是極度正常的。

因此編排和排程容器成為了最應當解決的問題，這也解釋了為什麼，即便這項技術不是很成熟，但仍有那麼多的排程器被開發出來，並且提供了不同的功能和選項。

排程器對比

從上一節我們可以看到，為了讓容器一起協調工作，成為一個真正的服務，在很多情況下，容器排程器都是有必要存在的。

首先，我們會從一個簡單的例子（只有兩個容器執行）來對比每個排程器。為了方便，我們使用Docker提供的初學者教程中的案例專案，這個專案會執行一個快餐車的網站[47]，並且將它部署到叢集上。

然後，我們會從另外一個例子來對比不同調度器的擴充套件性：基於AWS的投票應用。這個例子基於Docker提供的“try Swarm at scale”教程[7]。應用中所有的模組都執行在容器中，而容器執行在不同的節點，並且這個應用被設計成可擴充套件的：

Voting application architecture, © Docker Inc [7]

負載均衡負責管理執行Flask應用[1]的web伺服器和關聯佇列的數量。Worker層掃描Redis佇列，將投票出列，並且將重複項提交到執行在其他節點的Postgres容器。

快餐車應用（Food Trucks Application）

在這一節我們主要對比每個排程器的預設配置，比如說由於使用者需求極速增長所帶來的單容器瓶頸問題，還有如何處理一個需要重啟的容器。

我們想要執行的多容器環境是由一個執行擁有Flask程序的容器[1]，和其他執行有Elasticsearch程序的容器組成。

Swarm

Docker公司提供了多個工具，我們已經看到了Docker引擎和Swarm，但Doccker Compose才是多容器環境的關鍵。有了這個工具，我們能夠僅僅使用一個檔案來定義和執行多個容器。

對於我們現在的例子，我們可以使用一個docker-compose.yml檔案來指定兩個需要執行的映象（一個定製的Flask映象和一個Elasticsearch映象）和Swarm之間的關聯。

一個主要的問題就是Swarm可以像單主機Docker例項一樣，從一個Dockerfile來構建映象，但是構建的映象只能在單一節點上執行，而不能夠被分佈到叢集上的其他節點上。因此，應用被認為是一個容器，這種方式不是細粒度的。

如果我們使用docker-compose scale來擴充套件其中一個容器（附錄 B），這個新的容器將會根據排程器規則進行排程。如果容器負載過重，Docker Swarm並不會自動擴充套件容器，這對於我們的例子來說是一個大問題：我們必須經常去檢查下使用者訪問量是否達到瓶頸。

如果一個容器宕機了，Swarm並不會跟蹤一個服務應該有多少個例項在執行，因此它不會建立一個新的容器。其外，想要在某些容器上滾動更新也是不可能的，一個符合Docker思想的特性是非常有用的：能夠快速啟動和停止無狀態的容器。

Mesos & Marathon

與直接使用docker-compose.yml檔案不同，我們需要給Marathon一個具體的定義。第一個定義應用於Elasticsearch（附錄C），我們使用所有的預設配置，並不使用排程器的特性；在這種情況下，定義非常的簡單，並且類似於我們之間的docker-compose.yml檔案。應用於Flask的定義（附錄D）使用了更多Mesos的特性，包括指定CPU/RAM資訊和健康檢查。

Mesos提供了一個更加強大的定義檔案，因為容器和需求都可以被描述。相比於Swarm，這種方式並不簡單，但是它能夠很簡單的擴充套件服務，比如說，通過修改應用定義中的容器例項來擴充套件。（在Flask定義中設定數量為2）

相關推薦