www色中色,九九爱视频,亚洲一区二区三区在线播放

容器與容器編排

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

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

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

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

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

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

經(jīng)過多年的發(fā)展，Docker已經(jīng)開始被考慮在生產(chǎn)環(huán)境中進行部署使用了。為了推進Docker技術(shù)的商業(yè)化進展，在實際生產(chǎn)環(huán)境中，在多臺物理主機中協(xié)調(diào)容器資源成為首要要解決的問題。這一問題被統(tǒng)稱為容器編排。容器領(lǐng)域現(xiàn)階段爭論的重點也正在于為容器主機群管理提供怎樣容器編排架構(gòu)與功能。

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

Docker Swarm

Swarm是Docker自己的容器編排工具。它使用標準的Docker API和網(wǎng)絡(luò)，易于融入已經(jīng)使用Docker容器的環(huán)境中。

圖 1 Docker Swarm 架構(gòu)示意圖

（來源：ibm developerworks）

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

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

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

Kubernetes

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

圖 2 Kubernetes架構(gòu)圖示

（來源：Wikipedia）

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

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

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

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

Mesos和Marathon

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

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

圖 3 基于Mesos的容器編排架構(gòu)

（來源： Apache Mesos）

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

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

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

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

結(jié)論

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

表格 1 容器編排技術(shù)選型

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

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

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

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

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

關(guān)聯(lián)公眾號

關(guān)聯(lián)公眾號

嚴正聲明

聯(lián)系我們

售后服務(wù)

【曙光大數(shù)據(jù)實驗室】第一期丨容器編排技術(shù)概覽