容器與容器編排

在相當長的時間里，“把應用程序部署到生產環境中去”，許多資深研發和運維人員都有很多故事可以講。系統上線過程中，各種說不清道不明的靈異事件，層出不窮。這一窘境讓很多IT從業者對軟件開發所面臨的風險心懷畏懼，企業技術升級迭代也因此受阻。

Chef，Puppet，Ansible，持續集成和部署這些工具的出現，使測試和部署的標準化更加容易。這些工具把開發人員和運維人員從瑣碎的部署運維細節中解救了出來。近些年火起來的容器也可以標準化環境并抽象出硬件和底層操作系統的細節。

容器是一種軟件技術，它給操作系統級的虛擬化提供了一個抽象和自動化層。Docker 是開源的廣泛應用的容器引擎。Docker產生的初衷是為了克服部署在同一系統中的多個應用之間的庫和依賴的版本沖突問題。

為了減輕用戶在處理系統配置問題上的負擔，Docker利用Linux的cgroups和namespaces的功能，將應用及其依賴封裝在特殊的包中。這個包就是容器的鏡像，只要是裝了Docker引擎的系統上，都可以根據鏡像來創建容器實例并運行。不會受系統中其它容器或者系統本身安裝的依賴的影響。這種讓開發者可以打包他們的應用以及依賴包到一個可移植的容器中，然后發布到任何流行的 Linux 機器上的技術。

Docker由Solomon Hykes創建于2013年。到2017年，它已經成為用于部署的最熱門的開源項目之一。Docker在開發和運維領域發展勢頭正猛。其中一個主要原因就是它具有跨環境的一致性。

Docker非常適合持續部署和測試。Docker容器能在多個開發和發布周期之間保持一致性，有助于標準化運行環境。單個的容器主機本身可以把開發和生產環境中從底部抽象出來，但是在實際生產環境中只使用Docker容器，還會面臨諸多問題。

經過多年的發展，Docker已經開始被考慮在生產環境中進行部署使用了。為了推進Docker技術的商業化進展，在實際生產環境中，在多臺物理主機中協調容器資源成為首要要解決的問題。這一問題被統稱為容器編排。容器領域現階段爭論的重點也正在于為容器主機群管理提供怎樣容器編排架構與功能。

目前比較流行的容器編排工具包括Docker Swarm，Kubernetes和Mesos+Marathon。容器編排讓容器使用者不必去考慮哪個服務將托管于哪個特定容器，也不用關注對容器的啟停，監控等具體的操作。容器使用的最核心問題也恰是容器編排，如何部署和管理這些容器。Docker Swarm，Kubernetes，Mesos+Marathon都可用于容器的部署、管理以及實現基于容器的應用擴縮容，但這三種容器編排工具著重處理和適用的問題是非常不同的。這些容器編排工具在架構、周邊生態環境等方面也都不盡相同。

Docker Swarm

Swarm是Docker自己的容器編排工具。它使用標準的Docker API和網絡，易于融入已經使用Docker容器的環境中。

圖 1 Docker Swarm 架構示意圖

（來源：ibm developerworks）

如圖 1所示，Swarm由管理器和運行服務的工作節點組成。管理器在整個集群中分配任務，一個管理器協調管理眾多構成群集的工作節點。工作節點運行管理器分配的Docker容器。服務是在群集中運行的某組特定Docker容器的接口。任務是某特定服務所需的命令以及運行鏡像的Docker容器。Swarm的設置簡單。使用Docker Engine來啟動主節點，并可提供一個可在每個工作節點上使用的命令以將這些節點添加到集群。群集一旦運行，可使用Docker Compose指定服務。服務啟動后，它們將部署在群集的各個主機上，而不是單個主機上。用戶定義的任何網絡也可以跨整個群集工作。

Swarm有一定的模塊化, 用戶可以置換出鍵值存儲，并且已有實驗使用 Mesos 作為備用調度程序。Swarm不僅以容器為中心, 而且是以Docker為中心。Docker公司在Docker Swarm投入了大量精力，所以其發展迅速。

到目前為止，Swarm 已被認為至少是適合于實驗和小規模部署的，雖然它還是不如 Kubernetes 和 Mesos承認度高。Docker Swarm 提供了一個輕松的方式來進行容器編排，且不違背對現有 Docker 工具和思維的熟悉度。

Kubernetes

Kubernetes基于Google在生產環境中大規模工作負載經驗，雖然不是Google容器編排系統Borg的開放源碼，但是借鑒了Google從運行Borg獲得的經驗教訓。Kubernetes是受Google內部管理系統Borg啟發而催生的一個新的開源項目。Borg曾經號稱是Google內部最重要的系統，更可以說是Google的秘密武器。2016年3月，Google把Kubernetes項目交給了CNCF來維護，但Google還仍然是Kubernetes的主要貢獻力量。

圖 2 Kubernetes架構圖示

（來源：Wikipedia）

Swarm始于擴展單主機Docker，而Kubernetes的起始點就是集群本身。使用Kubernetes,須跳出Docker思維模式。如圖 2所示，Kubernetes集群默認情況下，單個master處理API調用，分配工作負載并維護配置狀態。Minion是運行工作負載和其他任何不在master上的工作的服務器。Pods是一些由一個或幾個部署在同一主機上的容器組成的計算能力單位，它們共同執行任務，且在pods內具有單個IP地址和網絡。服務是pods的負載平衡器和前端，它可提供一個浮動IP用于訪問為服務提供支持的pods，這意味著在pod發生更改的同時可以保持接口穩定。復制控制器負責維護pod的多個副本。標簽是用戶和系統用于標識pod，復制控制器和服務的鍵值標記。

使用Kubernetes與單獨使用Docker的方式不同。雖然Kubernetes的CLI和API與Docker的不同，但因其風頭正勁，所以找到適用的組件大多數情況還是可以辦到的。模塊化是Kubernetes方法的基礎。例如，用戶可以選擇Flannel，Weave，Calico和其他網絡選項。用戶也可以置換出stock調度程序而使用Mesos代替。這種模塊化還可以擴展到容器本身。

Kubernetes不僅限于在Docker上使用，它還可以使用rkt和其他容器格式。Kubernetes對于應用開發人員來說是降低對基礎設施和運維人員依賴性的利器。Kubernetes功能豐富。基于Kubernetes來開發商業化的容器云產品也相對容易。部署和運維Kubernetes的難度也比早期下降了不少。Kubernetes是在CNCF管理下的開源項目，比起受控于Docker公司的Docker Swarm，更加吸引開源貢獻者。Kubernetes的核心訴求是為便利無狀態Docker容器的運維管理。Kubernetes在有狀態服務和大數據方面也有意要推進，但是目前沒有得到充分的發展。因而有狀態服務和大數據應用要采用Kubernetes，目前并不是合適的選擇。

Kubernetes非常適合運行復雜應用程序的中大型集群。如果用戶有多套無狀態微服務器，那么Kubernetes可以提供一個框架以建立它們之間的交互規則并運行這個結構。Kubernetes到目前為止還是不太適合要運行有狀態的應用程序（如數據庫）的用戶，已開始支持具有配置依賴項并需要有狀態的失效備援的“pet”式容器。Kubernetes的學習曲線和設置比Docker Swarm需要花費更多的精力，但是它模塊化做得比較好，具有靈活性，適應于大規模部署應用的部署。

Mesos和Marathon

Apache Mesos比Docker出現得更早，被稱做是分布式系統內核。Mesos抽象了多臺計算機，形成單一邏輯視圖。Mesos是使計算資源可用于框架的集群管理器。Marathon是一個專門在Mesos集群上運行應用程序和容器的計算框架。Marathon早在2014年就提供了對Docker鏡像的支持。Mesos和Marathon在一起提供了相當于Kubernetes的功能，但卻同時支持非容器化的工作負載。

Mesos采用模塊化的架構設計，被Twitter、Uber、Apple、Netflix等公司所青睞，不僅僅支持微服務，還支持大數據和實時數據分析等。Mesos是集群資源管理工具，和Kubernetes所處理的問題屬于不同的層次。Mesos將數據數據中心資源抽象為統一的資源池，打破不同的業務負載的資源分配界限以提高資源分配的效率。Mesos集群管理的自動化工具豐富，可以為集群架構高容錯高可用。擴展集群功能和規模時，不會對原先部署在集群上的應用以及集群管理系統產生影響。

圖 3 基于Mesos的容器編排架構

（來源： Apache Mesos）

如圖 3所示，Mesos運行兩級調度。Mesos從節點向主節點報告自己的可用資源。Mesos根據先前設置的策略將該資源提供給上層計算框架。計算框架再根據定義的策略將資源提供給進程。在Mesos上層可以同時運行多個計算框架，例如Marathon、Cassandra、Storm、Spark。Marathon還可以來部署其他計算框架，來利用Marathon的健康檢查功能來實現計算框架的高可用。

Mesos上的應用負載可以是各種類型的，如無狀態微服務、批處理任務、有狀態服務、實時數據分析處理任務以及傳統應用。Mesos集群用Zookeeper管理至少三個主節點，并通過規定這些節點的額定數目來實現高可用性。從節點運行框架傳遞的任務。Mesos本身對工作負載一無所知，而計算框架決定如何處理Mesos提供給它們的資源。在Mesos頂層，Marathon是高可用性的計算框架。通過專用的DNS服務以及其他選項提供服務發現。通過HAProxy提供負載平衡。為了控制集群中某些工作負載的運行位置，約束管理為這些工作負載維護一定的資源水平，實現機架感知和其他約束。用戶可以在集群上運行的長期運行Docker容器或其他類型的工作負載。REST API可以用于部署，更改和銷毀工作負載。

Mesos和Marathon都可擴展到上萬節點規模。對于相對較小的集群，這么大的系統資源運行和管理開銷并不太合適。特別是與Docker Swarm相比，它的設置也更加復雜。Mesos和Marathon的使用也和Swarm或Kubernetes有所不同。它有另一套工具和API。

Mesos已在生產環境中被成千上萬的節點證明了可靠性。Mesos和Marathon比Kubernetes或Swarm出現時間更早有更多的驗證助其修復bug并在大規模的長期運行的實踐中收獲了用戶群。如果用戶需要與容器同時運行非容器式工作負載且運行規模巨大，Mesos和Marathon是不二之選。但它的學習曲線更陡峭。

結論

無論選擇Kubernetes、Docker Swarm還是Mesos+Marathon作為容器編排技術路線，都可以用來管理容器實踐基于容器來打包應用這種方式的可移植和可擴展性。對于不同編排方式的選擇，最根本的還是要根據上層業務的實際需求。

表格 1 容器編排技術選型

如表格 1所示，如果上層應用的需求是構建一個穩定的，業務類型混雜的容器平臺，那么Mesos+Marathon是最恰當的選擇。這種架構甚至可以將公有云資源納管進來，對復雜多變的甚至不確定的用戶需求非常實用。如果要采用當前流行的Kubernetes，那么評估一下實際的應用場景是不是專注于Devops以及持續集成，對數據分析處理以及其他業務是否也有潛在的容器化需求。當然，并不是所有想用Docker的團隊都得花精力來跟Kubernetes和 Mesos+Marathon這樣的高復雜性的技術架構打交道。如果團隊的目的只是將自己的應用以Docker容器的形式來打包，以適應容器這種虛擬化技術以及應用微服務化的這種發展趨勢。方便搭建使用的Docker Swarm就夠用了。

如果暫時應用場景不明確，為了構建容器平臺而構建，也不用感到困惑。因為，上容器平臺這個選擇，無論選擇了哪種技術路線，都會方便計算存儲資源的高效利用，讓軟件開發以及應用打包方式更加靈活以及適應于容器化這一明朗的IT架構發展趨勢。在這種情況下，編排管理工具的選擇則可以從其它方面來考慮。

目前容器編排相關標準化工作還不夠到位，找到一個滿足企業個性化需求的集群管理方案并不容易。對于容器初級用戶，這三者間兩個最大的差異就是它們的學習曲線和可擴展性了。團隊技能和人數是不可忽視的因素，這決定了企業可以在多大程度上優化集群管理器以實現最佳配置。Docker Swarm最便于使用， Docker API靈活性，易于集成，還可以用自定義接口和調度來定制腳本或構建應用等。Kubernetes更加通用，開源社區發展迅速。Mesos和Marathon更加適用于大型系統，有最大的冗余。Kubernetes和Mesos靈活性開放性更高，但是開發運維工作量對IT團隊要求比較高。Mesos最適用于已經運行數百或數千臺主機的公司，并且已經在上萬節點規模上得到了證實，適用于大規模數據解決方案。Swarm對于中小型系統，價值極大，易于擴展。Kubernetes最適合中等規模，高度冗余的系統，對技術團隊要求較高。Mesos是最穩定的平臺，但對于10-20個節點的小型系統來說過于復雜。

這三個主要容器編排工具在實現以及與用戶互動方式上有很大差異。Docker的Swarm提供了編排Docker主機群集的最簡單的方式。Kubernetes以容器為中心，但相對于容器本身，更多著力于部署和管理。Marathon的Mesos可以承載巨大的規模，使用復雜性也不低。當然，在實際項目需求中，單靠文檔調研來確定技術路線選型無法做出最客觀的選擇。系統原型實測結合應用程序的工作原理以及負載分析僅可以輔助技術選型。

更多曙光相關資訊，歡迎搜索微信公眾號“中科曙光/sugoncn”，關注曙光公司官方微信