基于容器的調(diào)度及通信技術(shù)研究*

楊 林

（國網(wǎng)河南省電力公司焦作供電公司，河南 焦作 454150）

0 引 言

云計算技術(shù)目前已經(jīng)在各行各業(yè)得到廣泛應(yīng)用，虛擬化技術(shù)是云計算的基礎(chǔ)，能夠把物理資源映射為虛擬資源，從而在最大程度上提高了物理資源的利用率。傳統(tǒng)的虛擬化技術(shù)在創(chuàng)建及銷毀實(shí)例的過程中，都需要很大的資源和時間開銷；最重要的是，如果要大規(guī)模的部署使用，隨著服務(wù)器數(shù)量的增加，傳統(tǒng)虛擬化技術(shù)的缺陷會被進(jìn)一步放大。

Docker容器技術(shù)是一種全新的基于Linux Container容器引擎的輕量級虛擬化技術(shù)，能夠?qū)崿F(xiàn)應(yīng)用的高效部署，同時保證資源的隔離。

1 Docker及容器技術(shù)

Unix系統(tǒng)下的chroot是最早的容器技術(shù)，目的是把root用戶的資源轉(zhuǎn)移到其他位置，并僅僅允許指定進(jìn)程訪問，從而實(shí)現(xiàn)不同進(jìn)程的隔離。后來又先后出現(xiàn)了LXC容器技術(shù)、Docker容器技術(shù)等。Docker容器技術(shù)是dotCloud公司的開源項(xiàng)目，其中包含倉庫、鏡像模型、命令行工具以及REST API工具等和容器管理關(guān)聯(lián)的生態(tài)系統(tǒng)。

在Docker發(fā)布了正式版本后，RedHat也提供了對Docker的支持，隨后谷歌、亞馬遜、微軟等也先后宣布支持。谷歌于2015年首次公開了Kubernetes，將之作為Docker容器的編排工具。國內(nèi)的騰訊、京東等公司先后在生產(chǎn)系統(tǒng)中使用Docker容器技術(shù)。

Docker容器技術(shù)的隔離是通過完全沙箱的方式實(shí)現(xiàn)的，因此即使兩個容器運(yùn)行在同一宿主機(jī)上，也不會有直接訪問的接口，從而保證了資源的獨(dú)立訪問。另外，容器和宿主機(jī)間共享內(nèi)核資源，從而降低了資源運(yùn)行時需要的開銷。

2 容器技術(shù)中的調(diào)度策略

雖然Docker在應(yīng)用的分發(fā)、部署等方面具有巨大的優(yōu)勢，然而隨著Docker在服務(wù)器集群上的應(yīng)用范圍逐漸擴(kuò)大，如何提高Docker集群中任務(wù)調(diào)度的效率、最大化集群資源的利用率已經(jīng)是一個重要的現(xiàn)實(shí)問題。另外，Docker容器中的網(wǎng)絡(luò)應(yīng)用也越來越多，從而對Docker的網(wǎng)絡(luò)通信技術(shù)提出越來越高的要求。這樣一來，如何保證部署不同應(yīng)用的Docker容器間的通信質(zhì)量，也成為一個巨大的挑戰(zhàn)。

2.1 容器集群

隨著部署在Docker容器中的應(yīng)用越來越多，容器的規(guī)模也不斷增加，僅僅在單個宿主機(jī)上構(gòu)建容器無疑會導(dǎo)致瓶頸，因此使用Docker集群就成為理所當(dāng)然的事情。

Docker集群對外是一個單一的服務(wù)實(shí)體，由多個相互獨(dú)立的服務(wù)器個體組成。集群一般有兩大特性[1]：（1）負(fù)載均衡。用戶請求或數(shù)據(jù)會根據(jù)一定的均衡原則分?jǐn)偟郊褐械亩鄠€實(shí)體上執(zhí)行，從而可以按照不同服務(wù)器的實(shí)際處理能力分配相稱的任務(wù)；在充分利用集群內(nèi)各種資源的基礎(chǔ)上，最小化任務(wù)的執(zhí)行時間，同時提升集群的處理能力。（2）故障恢復(fù)。如果集群中的服務(wù)器因?yàn)橘Y源短缺或故障原因無法繼續(xù)執(zhí)行任務(wù)，則需要從集群中選擇合適的節(jié)點(diǎn)繼續(xù)執(zhí)行。

Docker集群中的所有節(jié)點(diǎn)都部署了Docker服務(wù)，各節(jié)點(diǎn)上的物理資源分配給需要的Docker容器使用。和傳統(tǒng)集群不同的是，Docker集群除了包含物理節(jié)點(diǎn)外，還包括各物理節(jié)點(diǎn)上的Docker容器；這種多層次的Docker容器集群在實(shí)現(xiàn)負(fù)載均衡和故障恢復(fù)時，就不能簡單的應(yīng)用傳統(tǒng)集群的調(diào)度策略，需要一種合理而又高效的調(diào)度策略完成Docker容器集群的任務(wù)調(diào)度工作。

目前在部署并管理Docker容器集群時，已經(jīng)有集中使用廣泛的工具，主要包括[2]：（1）Kubernetes。谷歌在多年Docker容器開發(fā)經(jīng)驗(yàn)的基礎(chǔ)上，為Docker集群提供的資源調(diào)度、負(fù)載均衡套件。雖然Kubernetes提高了Docker集群的管理能力，但由于其學(xué)習(xí)成本較高，因此并沒有被推廣到多數(shù)應(yīng)用Docker的場合。（2）Swarm。Docker官方提供的集群工具，具備資源調(diào)度、負(fù)載均衡以及服務(wù)發(fā)現(xiàn)的能力，不需要額外的學(xué)習(xí)成本，因此應(yīng)用范圍比較廣。然而，Swarm的負(fù)載均衡策略比較簡單，并且其故障恢復(fù)功能不佳。和Kubernetes相比的優(yōu)勢在于不需要針對Docker做定制化的修改。（3）Mesos。Apache旗下的比較成熟的分布式管理框架，其分布式容錯特性能夠解決多數(shù)分布式集群調(diào)度問題。需要注意的是，Mesos應(yīng)用于Docker集群時需要對Docker進(jìn)行定制化修改，無疑提高了使用成本。

2.2 容器集群的調(diào)度策略及其優(yōu)化

Docker Swarm構(gòu)建的Docker集群如圖1所示。

圖1 Docker Swarm集群

其中Swarm為Docker客戶端提供API，從而保證Swarm集群中運(yùn)行容器能像單個宿主機(jī)上運(yùn)行容器那樣執(zhí)行同樣的命令，以便借助Swarm集群進(jìn)行任務(wù)調(diào)度。

Swarm進(jìn)行任務(wù)調(diào)度的過程如圖2所示。

圖2 Swarm任務(wù)調(diào)度示意

在客戶端請求Request發(fā)送到Docker Swarm時，Swarm會判斷請求中是否有限定條件，如果有則借助Filter Chain模塊篩選出符合條件的節(jié)點(diǎn)，隨之根據(jù)既定策略把所有篩選出的節(jié)點(diǎn)排序，并選擇排名最高的節(jié)點(diǎn)作為調(diào)度執(zhí)行節(jié)點(diǎn)。

Swarm集群的調(diào)度策略主要包括3種[3]：隨機(jī)調(diào)度策略、密集型調(diào)度策略以及擴(kuò)散型調(diào)度策略。顧名思義，隨機(jī)型調(diào)度策略會隨機(jī)選擇調(diào)度節(jié)點(diǎn)，實(shí)際應(yīng)用中通常用作任務(wù)調(diào)度策略的調(diào)試，以便檢驗(yàn)Swarm集群的連通性。密集型策略會根據(jù)不同集群節(jié)點(diǎn)的內(nèi)存、CPU資源計算各節(jié)點(diǎn)的權(quán)重，在任務(wù)調(diào)度請求到達(dá)時會盡量將任務(wù)集中部署到一個節(jié)點(diǎn)上，當(dāng)此節(jié)點(diǎn)無法再繼續(xù)接受任務(wù)時再選擇其他節(jié)點(diǎn)調(diào)度。擴(kuò)散型策略在有調(diào)度請求時，會把每個調(diào)度請求均勻地分配到每個節(jié)點(diǎn)，以確保最大化利用每個節(jié)點(diǎn)的資源使用率。

密集型調(diào)度策略以及擴(kuò)散型調(diào)度策略在進(jìn)行任務(wù)調(diào)度時，本質(zhì)上都是利用集群中各節(jié)點(diǎn)的內(nèi)存及CPU資源進(jìn)行動態(tài)加權(quán)負(fù)載均衡，并沒有考慮各節(jié)點(diǎn)的網(wǎng)絡(luò)帶寬資源。可以以此為切入點(diǎn)對任務(wù)調(diào)度策略進(jìn)行優(yōu)化：計算各節(jié)點(diǎn)流入/流程網(wǎng)卡上的雙向流量占最大數(shù)據(jù)處理能力的比重，以此衡量單位時間內(nèi)不同節(jié)點(diǎn)網(wǎng)絡(luò)資源的權(quán)重。

在解決了容器集群負(fù)載均衡沒有考慮網(wǎng)絡(luò)資源的前提下，為了克服各資源的權(quán)重設(shè)置不合理的問題，可以為每種資源的權(quán)重引入一個二次調(diào)節(jié)因子，進(jìn)而根據(jù)集群節(jié)點(diǎn)實(shí)時的負(fù)載情況動態(tài)調(diào)整權(quán)重。

3 容器技術(shù)中的通信技術(shù)

3.1 Docker容器的通信技術(shù)

容器的一大特性就是其資源隔離性，Docker容器借助Network Namespace實(shí)現(xiàn)了網(wǎng)絡(luò)設(shè)備、IP路由表等各種網(wǎng)絡(luò)資源的隔離。Docker容器自身并沒有網(wǎng)絡(luò)設(shè)備，在需要進(jìn)行網(wǎng)絡(luò)通信時借助虛擬網(wǎng)橋以及Veth pair實(shí)現(xiàn)網(wǎng)絡(luò)虛擬化。

Docker支持4種網(wǎng)絡(luò)模式[4]：（1）bridge模式。在bridge模式中，Docker Daemon創(chuàng)建一個網(wǎng)橋，并在創(chuàng)建容器時創(chuàng)建一組veth pair網(wǎng)絡(luò)設(shè)備對，用于容器和Docker宿主機(jī)的網(wǎng)絡(luò)通信；雖然實(shí)現(xiàn)了容器間的連通及隔離性，但是宿主機(jī)及容器間的網(wǎng)絡(luò)地址不在同一網(wǎng)段，即使NAT映射能夠?qū)崿F(xiàn)宿主機(jī)和容器間的網(wǎng)絡(luò)傳輸，但在網(wǎng)絡(luò)負(fù)載時這種單一的方式會成為網(wǎng)絡(luò)及性能瓶頸。（2）host模式。容器中不創(chuàng)建與宿主機(jī)隔離的網(wǎng)絡(luò)環(huán)境，而是與宿主機(jī)共用各種網(wǎng)絡(luò)資源，可以直接與容器外部通信。（3）container模式。和已存在的容器共享網(wǎng)絡(luò)資源，但其他系統(tǒng)資源還是隔離的。（4）None模式。容器不進(jìn)行任何網(wǎng)絡(luò)配置，用戶可以根據(jù)需求定制網(wǎng)絡(luò)。

以上的網(wǎng)絡(luò)通信模式都存在各自的弊端，加之隨著Docker容器技術(shù)在云端的應(yīng)用不斷增加，需要的網(wǎng)絡(luò)服務(wù)類型也更加多樣化，因此需要日益復(fù)雜的網(wǎng)絡(luò)設(shè)置，需要有完善的網(wǎng)絡(luò)Qos功能的支持，然而目前的Docker通信模塊中并不支持。

為克服Docker容器在網(wǎng)絡(luò)通信上的不足之處，通常使用第三方工具來定制網(wǎng)絡(luò)通信方式，常用的網(wǎng)絡(luò)通信定制工具有[5]：（1）Open vSwitch（OVS）?？梢詫?shí)現(xiàn)容器間的通信，并且其內(nèi)置的Qos模塊可以很好的對網(wǎng)絡(luò)服務(wù)進(jìn)行質(zhì)量控制；然而，OVS是重量級的工具，不適合中小應(yīng)用。（2）Flannel。雖然能夠?yàn)槿萜骷褐械乃泄?jié)點(diǎn)重新規(guī)劃并分配IP，但是部署相對復(fù)雜，大規(guī)模的集群節(jié)點(diǎn)會增加配置部署的復(fù)雜度；更重要的是并沒有Qos服務(wù)質(zhì)量控制。（3）Linux系統(tǒng)內(nèi)置的流量控制以及Cgroups。雖然具備Qos服務(wù)質(zhì)量控制功能，但是創(chuàng)建容器時需要指定固定的大小，難以實(shí)現(xiàn)動態(tài)網(wǎng)絡(luò)控制，而且需要修改內(nèi)核，擴(kuò)展性相對較差。

從上述分析可知，目前容器通信技術(shù)存在一定缺陷，各解決方案大多是針對特定應(yīng)用場景，如果想要為容器提供完善的通信模式還需要進(jìn)一步優(yōu)化。

3.2 Docker容器的通信優(yōu)化

原生的Docker容器中對網(wǎng)絡(luò)通信資源的管理粒度較粗，為細(xì)化管理粒度，可以根據(jù)通信資源使用不同優(yōu)先級的隊(duì)列，并進(jìn)行自適應(yīng)帶寬控制。實(shí)現(xiàn)方式是[6]：

（1）指定容器的優(yōu)先級。創(chuàng)建容器的時候，根據(jù)容器中運(yùn)行應(yīng)用的優(yōu)先程度將其劃分為不同程度的優(yōu)先級，高優(yōu)先級的容器優(yōu)，先被分配網(wǎng)絡(luò)資源。（2）創(chuàng)建優(yōu)先級隊(duì)列。初始化時為每一優(yōu)先級創(chuàng)建對應(yīng)的隊(duì)列，以緩沖各自優(yōu)先級的網(wǎng)絡(luò)流量。容器中應(yīng)用發(fā)出的網(wǎng)絡(luò)流量會先緩存在對應(yīng)優(yōu)先級隊(duì)列中。（3）網(wǎng)絡(luò)流量處理。根據(jù)優(yōu)先級依次處理各隊(duì)列中的網(wǎng)絡(luò)數(shù)據(jù)包，根據(jù)實(shí)際需要進(jìn)行網(wǎng)絡(luò)地址轉(zhuǎn)換或數(shù)據(jù)轉(zhuǎn)發(fā)。

通過上述優(yōu)化，能夠保證關(guān)鍵服務(wù)使用較大的網(wǎng)絡(luò)帶寬，以此縮短其響應(yīng)時間。另外，普通的應(yīng)用也不會因?yàn)橐恢庇嘘P(guān)鍵服務(wù)運(yùn)行而長時間饑餓等待，即使在業(yè)務(wù)規(guī)模大的時候，也能夠根據(jù)自適應(yīng)調(diào)整獲取適當(dāng)?shù)耐ㄐ刨Y源。最重要的是還能夠根據(jù)實(shí)時的網(wǎng)絡(luò)資源使用情況動態(tài)調(diào)整資源的分配，提高通信性能。

4 結(jié) 語

本文對容器技術(shù)中的任務(wù)調(diào)度及通信技術(shù)進(jìn)行研究，并分析對應(yīng)的優(yōu)化策略。在任務(wù)調(diào)度優(yōu)化策略中，在進(jìn)行動態(tài)加權(quán)負(fù)載均衡時增加了各節(jié)點(diǎn)的網(wǎng)絡(luò)帶寬資源因子，并為每種資源的權(quán)重引入一個二次調(diào)節(jié)因子，進(jìn)而根據(jù)集群節(jié)點(diǎn)實(shí)時的負(fù)載情況動態(tài)調(diào)整權(quán)重。細(xì)化了網(wǎng)絡(luò)通信資源的管理粒度，方便容器中的應(yīng)用根據(jù)網(wǎng)絡(luò)情況動態(tài)調(diào)整通信資源。