王志偉　楊超

摘 要：針對Docker容器缺乏對網(wǎng)絡(luò)帶寬資源進(jìn)行限制的能力的問題，提出了一種基于流量控制（TC）的Docker容器網(wǎng)絡(luò)帶寬控制機(jī)制。首先，基于CGroups文件系統(tǒng)的實時監(jiān)測機(jī)制，利用Linux內(nèi)核的虛擬文件系統(tǒng)（VFS）作為媒介，將Docker容器創(chuàng)建時設(shè)置的網(wǎng)絡(luò)控制參數(shù)傳遞給Linux內(nèi)核流量控制器TC;然后，通過引入IFB模塊實現(xiàn)上下行帶寬控制，并使用rate、ceil及prio參數(shù)進(jìn)行空閑帶寬共享及容器優(yōu)先級控制;最后，控制TC執(zhí)行具體的網(wǎng)絡(luò)限制，以實現(xiàn)容器之間靈活的網(wǎng)絡(luò)資源控制。實驗結(jié)果表明，該機(jī)制在容器獨占帶寬場景下可有效地將實際容器帶寬限制在2%的波動范圍內(nèi)，而在共享空閑帶寬場景下可在平均誤差0.5%的范圍內(nèi)精準(zhǔn)限制容器帶寬，同時該機(jī)制能夠基于優(yōu)先級彈性地管理資源。該機(jī)制具有提供更為原生的接口且無需額外工具配合的優(yōu)勢，可為基于Docker的云平臺的細(xì)粒度彈性網(wǎng)絡(luò)資源控制提供便捷有效的解決思路。

關(guān)鍵詞：Docker容器;資源控制;網(wǎng)絡(luò)帶寬;CGroups機(jī)制;流量控制

中圖分類號： TP393計算機(jī)網(wǎng)絡(luò)文獻(xiàn)標(biāo)志碼：A

Bandwidth control mechanism for Docker container network based on

traffic control

WANG Zhiwei1， YANG Chao2*

（School of Computer Science and Information Engineering， Hubei University， Wuhan Hubei 430062， China）

Abstract： As Docker container lacks the ability of limiting network bandwidth resources， a bandwidth control mechanism was proposed for Docker container network based on Traffic Control （TC）. Firstly， based on the real-time monitoring mechanism of CGroups file system， Virtual File System （VFS） of Linux kernel was used as a medium to pass the network control parameters set when Docker container was created to the Linux kernel controller TC. Then， the Intermediate Functional Block device （IFB） module was introduced to archive uplink and downlink bandwidth control， and the parameters （rate， ceil and prio） were used to achieve idle bandwidth sharing and container priority control. Finally， the specific network limitations were conducted by controlling the TC， and flexible network resource control between containers was realized. The experimental results show that the proposed mechanism can effectively limit the actual container bandwidth within 2% fluctuation range in the container exclusive bandwidth scenario， and can precisely limit the network bandwidth of the container with average 0.5% error range in the shared idle bandwidth scenario. Meanwhile， the mechanism can flexibly manage resources based on priorities. With the advantage of providing a more native interface for Docker and requiring no additional tools， this mechanism can provide a convenient and effective solution for fine-grained elastic network resource control on Docker-based cloud platform.

Key words： Docker container; resource control; network bandwidth; CGroups mechanism; Traffic Control （TC）

0 引言

Linux容器技術(shù)是一種輕量級操作系統(tǒng)層的虛擬化技術(shù)。相對于傳統(tǒng)的虛擬機(jī)，Linux容器具有快速部署、輕量化、低成本、低資源消耗等顯著優(yōu)勢。其中，Docker容器是目前最成功的開源容器產(chǎn)品[1-3]。Docker具備持續(xù)集成、版本控制、可移植性、隔離性和安全性等重要優(yōu)勢，眾多企業(yè)和個人使用Docker來部署、測試、開發(fā)應(yīng)用，同時基于Docker來部署云平臺已經(jīng)是主流趨勢[4-6]。Docker容器技術(shù)被應(yīng)用在越來越多的領(lǐng)域[7-10]。

目前，Docker仍缺乏對容器網(wǎng)絡(luò)帶寬進(jìn)行限制的能力，增強Docker對于網(wǎng)絡(luò)帶寬資源進(jìn)行控制的能力，并且采用一種彈性和基于優(yōu)先級的網(wǎng)絡(luò)帶寬資源管理方式對Docker云平臺的資源管理至關(guān)重要[11]。Zheng等[12]指出Docker默認(rèn)的本地訪問控制是非常弱的，默認(rèn)的安裝策略包含對網(wǎng)卡設(shè)備和文件系統(tǒng)的全部訪問權(quán)限;但是相較于在單個容器級別限制對網(wǎng)卡的使用而言，對整個Docker限制網(wǎng)卡設(shè)備的使用是低效并且不夠靈活的。Khalid等[13]的研究表明如果不限制Docker容器對網(wǎng)絡(luò)的使用，攻擊者可以通過大量使用網(wǎng)絡(luò)資源來影響統(tǒng)一主機(jī)下其他用戶的使用。在此基礎(chǔ)上，Khalid等[13]又提出一種基于硬件的策略來改變Docker對網(wǎng)絡(luò)使用計時的方案，但是由于引入了特殊的硬件，所以對宿主機(jī)提出了新的要求。

本文在Linux內(nèi)核的層面設(shè)計一種精準(zhǔn)的Docker容器網(wǎng)絡(luò)帶寬（以Kb/s計算）控制系統(tǒng)，解決Docker對容器網(wǎng)絡(luò)帶寬資源缺少限制的問題，進(jìn)而有效地實現(xiàn)容器之間網(wǎng)絡(luò)資源的均衡，其優(yōu)勢在于：1）粒度細(xì)。限制是作用于容器實力級別而不是整個Docker系統(tǒng)。2）控制精準(zhǔn)。能夠以Kb/s的精準(zhǔn)程度控制容器的上行和下行速度。3）對系統(tǒng)要求低。能夠在不借助額外硬件的幫助下完成，更適合現(xiàn)行硬件條件的宿主機(jī)環(huán)境。該系統(tǒng)具備以下功能：

1）支持容器的網(wǎng)絡(luò)帶寬上行、下行帶寬在容器啟動時被獨立設(shè)定。

2）保證能夠利用到被分配到的IO帶寬額度。

3）具備彈性資源控制能力，在網(wǎng)絡(luò)帶寬有空閑資源時，可以按照主機(jī)額度來均分其他CGroups的空閑帶寬，不會浪費IO帶寬資源。

4）支持為不同服務(wù)的容器設(shè)定優(yōu)先級，確保對時延要求較高的服務(wù)的服務(wù)質(zhì)量。

1 相關(guān)工作

1.1 Docker現(xiàn)有資源限制的情況

在Docker中，默認(rèn)情況下容器的資源只受到host端內(nèi)核資源調(diào)度的限制，但是可以在使用Docker run命令啟動容器時添加一些資源控制標(biāo)志來控制容器的Memory、CPU以及Disk IO資源的分配。Docker借助了Linux內(nèi)核的namespace對資源進(jìn)行隔離，例如CPU資源、磁盤資源、網(wǎng)絡(luò)資源，然后又借助Linux內(nèi)核的CGroups對隔離的資源施加限制。由于Linux內(nèi)核雖然支持對網(wǎng)絡(luò)資源進(jìn)行隔離，卻并沒有支持對網(wǎng)絡(luò)資源的使用進(jìn)行限制，所以現(xiàn)有的方案一般都采用Docker搭配其他網(wǎng)絡(luò)資源限制的工具使用。

本文基于Linux內(nèi)核流量控制（Traffic Control， TC）[14]為Docker建立TC隊列，并為Docker容器建立分類和過濾器，使得每個容器的數(shù)據(jù)包都通過過濾器來確定分類，并最終達(dá)到限制容器網(wǎng)絡(luò)帶寬的目的。該方案能較為精準(zhǔn)地控制容器的上行和下行帶寬，并且支持共享限制帶寬和為容器設(shè)置優(yōu)先級。同時該方案能為Docker提供更為原生的使用接口，直接通過Docker參數(shù)指定而無需額外工具的配合。

1.2 Linux內(nèi)核流量控制器TC

Linux 操作系統(tǒng)中的TC用于Linux內(nèi)核的流量控制，它利用隊列規(guī)定建立處理數(shù)據(jù)包的隊列，并定義隊列中的數(shù)據(jù)包被發(fā)送的方式，從而實現(xiàn)對流量的控制。TC 模塊實現(xiàn)流量控制功能使用的隊列規(guī)定分為兩類：一類是無類隊列規(guī)定，另一類是分類隊列規(guī)定。無類隊列規(guī)定相對簡單，而分類隊列規(guī)定則引出了分類和過濾器等概念，使其流量控制功能增強。無類隊列規(guī)定是對進(jìn)入網(wǎng)絡(luò)設(shè)備（網(wǎng)卡）的數(shù)據(jù)流不加區(qū)分統(tǒng)一對待的隊列規(guī)定。使用無類隊列規(guī)定形成的隊列能夠接收數(shù)據(jù)包以及重新編排、延遲或丟棄數(shù)據(jù)包。這類隊列規(guī)定形成的隊列可以對整個網(wǎng)絡(luò)設(shè)備（網(wǎng)卡）的流量進(jìn)行整形，但不能細(xì)分各種情況。常用的無類隊列規(guī)定主要有先進(jìn)先出（First Input First Output， FIFO）、令牌桶過濾器（Token Bucket Filter， TBF）、隨機(jī)公平隊列（Stochastic Fairness Queue， SFQ）等。這類隊列規(guī)定使用的流量整形手段主要是排序、限速和丟包。

分類隊列規(guī)定是對進(jìn)入網(wǎng)絡(luò)設(shè)備的數(shù)據(jù)包根據(jù)不同的需求以分類的方式區(qū)分對待的隊列規(guī)定。數(shù)據(jù)包進(jìn)入一個分類的隊列后，它就需要被送到某一個類中，也就是說需要對數(shù)據(jù)包作分類處理。對數(shù)據(jù)包進(jìn)行分類的工具是過濾器，過濾器會返回一個決定，隊列規(guī)定就根據(jù)這個決定把數(shù)據(jù)包送入相應(yīng)的類進(jìn)行排隊。每個子類都可以再次使用它們的過濾器進(jìn)行進(jìn)一步的分類，直到不需要進(jìn)一步分類時，數(shù)據(jù)包才進(jìn)入該類包含的隊列排隊。除了能夠包含其他隊列規(guī)定之外，絕大多數(shù)分類的隊列規(guī)定還能夠?qū)α髁窟M(jìn)行整形。這對于需要同時進(jìn)行調(diào)度（如使用SFQ）和流量控制的場合非常有用。Linux流量控制主要分為建立隊列、建立分類和建立過濾器三個方面，基本實現(xiàn)步驟如下：

1）針對網(wǎng)絡(luò)物理設(shè)備（如以太網(wǎng)卡eth0）綁定一個隊列qdisc，在該隊列上建立分類class;

2）為每一分類建立一個基于路由的過濾器filter;

3）最后與過濾器相配合，建立特定的路由表。

2 網(wǎng)絡(luò)帶寬控制系統(tǒng)實現(xiàn)

2.1 系統(tǒng)總體架構(gòu)

本文方案主要是基于TC來實現(xiàn)對Docker的網(wǎng)絡(luò)帶寬進(jìn)行限制，基于Linux的內(nèi)核模塊可以使依賴降到最低，同時通過在Docker內(nèi)集成TC能夠更加準(zhǔn)確地收集容器信息從而精準(zhǔn)地控制網(wǎng)絡(luò)帶寬，另外可以向Docker提供和原生類似的一致接口。

Linux內(nèi)核從2.2版本開始已經(jīng)支持使用TC命令實現(xiàn)了流量控制的功能，TC功能十分強大，利用TC完全能夠?qū)崿F(xiàn)對網(wǎng)絡(luò)帶寬的控制。但是為了使用戶態(tài)工具TC和Docker進(jìn)行協(xié)調(diào)配合，針對網(wǎng)絡(luò)帶寬設(shè)計了一種基于CGroups文件系統(tǒng)實時監(jiān)測機(jī)制，利用內(nèi)核CGroups系統(tǒng)實現(xiàn)的虛擬文件系統(tǒng)（Virtual File System， VFS）作為媒介，將Docker容器創(chuàng)建時設(shè)置的網(wǎng)絡(luò)控制參數(shù)傳遞給TC。所設(shè)計系統(tǒng)的技術(shù)流圖如圖1所示。

圖2展示了網(wǎng)絡(luò)帶寬控制系統(tǒng)的總體架構(gòu)。在用戶空間，通過定制Docker源碼，實現(xiàn)對混合CGroups的支持，同時利用CGroups文件系統(tǒng)為媒介，用戶態(tài)網(wǎng)絡(luò)帶寬控制模塊能夠感知Docker容器設(shè)置的變化，進(jìn)行相應(yīng)網(wǎng)絡(luò)帶寬控制。各模塊功能如下：

1）網(wǎng)絡(luò)帶寬Controller：作為用戶態(tài)Linux守護(hù)進(jìn)程，負(fù)責(zé)與Docker daemon配合進(jìn)行網(wǎng)絡(luò)帶寬的控制。

2）Net CGroups detector： 監(jiān)測CGroups文件系統(tǒng)內(nèi)net_ctls下Docker容器網(wǎng)絡(luò)控制的變化，能夠讀取網(wǎng)絡(luò)控制參數(shù)，將參數(shù)配置傳給TC controller模塊。

3）TC controller：接收從Net CGroups detector模塊傳遞的網(wǎng)絡(luò)控制指令和具體參數(shù)，控制TC執(zhí)行具體的網(wǎng)絡(luò)限制。

2.2 限制容器的上限帶寬

Docker啟動容器時默認(rèn)的網(wǎng)絡(luò)模式是bridge，該模式也是業(yè)界應(yīng)用最廣泛的一種網(wǎng)絡(luò)模式，該網(wǎng)絡(luò)模式的拓?fù)淙鐖D3所示。Docker在主機(jī)中建立了一個叫作docker0的網(wǎng)橋，而后容器與主機(jī)之間的流量都是通過這個網(wǎng)橋進(jìn)行轉(zhuǎn)發(fā)的。由于TC工具只能對網(wǎng)卡的發(fā)送速率進(jìn)行限制，因此容器的上下行帶寬設(shè)置方法有略微的不同，這里分開討論。

對于容器的下行流量，數(shù)據(jù)包是從eth0發(fā)送到docker0，而后再通過docker0發(fā)送到docker1（172.17.0.2）上。因此只要限制了docker0發(fā)往docker1（172.17.0.2）的速率，就可以限制容器docker1 的下行帶寬了。具體要做的操作有：

1）使用TC工具為docker0網(wǎng)橋添加一個qdisc，具體使用的是分層令牌桶（Hierarchical Token Bucket， HTB）[15]。

2）在這個qdisc上建立一個根分類（例如2∶1），可以選擇設(shè)置docker0網(wǎng)橋的總可用帶寬。

3）為容器建立子分類（例如2∶2），同時設(shè)置該分類的帶寬。

4）利用TC filter將目的地址為容器的IP的流量都?xì)w類為2∶2。

對于容器的上行流量，使用了Linux內(nèi)核的IFB（Intermediate Functional Block device）模塊，手動加載IFB模塊后，系統(tǒng)的網(wǎng)絡(luò)中將多出一個ifb0的設(shè)備，需要將docker0網(wǎng)卡從容器端接受到的所有流量都轉(zhuǎn)發(fā)到ifb0網(wǎng)卡，然后再用類似的方法限制帶寬。具體要做的操作有：1）加載IFB模塊;2）啟動ifb0設(shè)備;3）將docker0的流量轉(zhuǎn)發(fā)到ifb0設(shè)備上;4）為ifb0添加了qdisc，本文使用的HTB;5）在這個qdisc上建立根分類（3∶1），可以選擇設(shè)置所有容器總可用上行帶寬;6）為容器建立子分類（3∶2），同時設(shè)置該分類的帶寬;7）利用TC filter將源地址為容器的IP的流量都?xì)w類為3∶2。

2.3 支持容器共享空閑帶寬

在實際的生產(chǎn)環(huán)境中，有部分容器帶寬使用率很低，而有些容器的帶寬利用率很高，這就造成了資源的浪費，因此需要支持容器共享空閑帶寬。在使用TC工具為容器建立子分類時，可以限制容器的帶寬，限制帶寬有rate和ceil兩種選項：rate選項設(shè)置的帶寬是容器能夠被保證的帶寬，而ceil選項設(shè)置的帶寬是在父分類有空閑帶寬時，容器能夠得到的最大的帶寬。因此，如果需要設(shè)置容器可以共享空閑帶寬，只要調(diào)整這個ceil值，讓它大于rate值;如果不想讓容器共享空閑帶寬，那么只要設(shè)置這個ceil值與rate值相等即可。

2.4 支持為每個容器設(shè)定優(yōu)先級

Docker提倡一個容器只負(fù)責(zé)一種服務(wù)，不同的服務(wù)對網(wǎng)絡(luò)帶寬和時延的要求也不同，因此需要支持為容器設(shè)立優(yōu)先級，在網(wǎng)絡(luò)出現(xiàn)擁堵的情況下，具有高優(yōu)先級容器的數(shù)據(jù)包將被優(yōu)先處理，確保較低的延時，保證容器的服務(wù)質(zhì)量。TC工具支持為分類設(shè)置prio參數(shù)，該參數(shù)即可實現(xiàn)我們的需求，參數(shù)值越小優(yōu)先級越高，優(yōu)先級高的分類數(shù)據(jù)包將被優(yōu)先發(fā)送。

3 實驗結(jié)果與分析

3.1 實驗環(huán)境

為了驗證本文系統(tǒng)在限制容器上限網(wǎng)絡(luò)帶寬、按優(yōu)先級分配網(wǎng)絡(luò)帶寬和彈性分配帶寬等方面的效果，在實際的物理機(jī)上進(jìn)行了實驗驗證。實驗結(jié)果表明，本文系統(tǒng)能夠精確限制容器網(wǎng)絡(luò)帶寬，并按比例將空閑網(wǎng)絡(luò)帶寬分配給各個容器。

實驗首先測試對容器帶寬的上限進(jìn)行限制。在未限制帶寬的基準(zhǔn)測試中，容器全力下載則會耗盡所有帶寬，所以下載速率非常高，通過限制上限之后，即使容器全力下載其下載速率也不能突破施加的限制，從而說明施加的上限是有效的。

在驗證共享帶寬的實驗中，主機(jī)中同時啟動兩個容器，并且其對兩者施加的上限之和小于主機(jī)的帶寬上限。在這種資源閑置的情況下，通過設(shè)置不同的參數(shù)希望能夠使得容器突破上限使用閑置資源，所以容器的實際帶寬可能略大于上限，并且兩個容器實際使用的帶寬之和接近主機(jī)的帶寬上限，從而說明容器能夠有效利用空閑帶寬。

在驗證容器優(yōu)先級的實驗中，在上一個實驗環(huán)境的基礎(chǔ)上進(jìn)行。對上一實驗中的兩個容器設(shè)置不同的優(yōu)先級，原本兩個容器都能共享主機(jī)中空閑的帶寬，現(xiàn)在優(yōu)先級高的容器將優(yōu)先使用這些空閑帶寬，在高優(yōu)先級容器結(jié)束后低優(yōu)先級容器能繼續(xù)使用空閑帶寬，從而說明對容器的優(yōu)先級設(shè)定是有效的。

3.2 限制容器的上限帶寬

為了測試系統(tǒng)對容器帶寬的限制作用，在Docker中啟動一個容器后，不對它進(jìn)行任何的限制，在10s的時間間隔內(nèi)，每0.5s打印該時段內(nèi)傳輸字節(jié)量以及平均的傳輸速率，作為基準(zhǔn)線。重新啟動容器，并將rate設(shè)置為50Mb/s，其余ceil、prio參數(shù)默認(rèn)為無效，以同樣的時間間隔打印測試結(jié)果，結(jié)果如圖4所示。

從圖4中可以觀察到，剛啟動容器時，傳輸速率較大，但會迅速下落。當(dāng)不作任何帶寬限制時，實際傳輸速率波動幅度較大，總體保持在較高水平。當(dāng)限制帶寬為50Mb/s，啟動容器后實際傳輸速率能迅速回落至設(shè)定值，且波動幅度極小，不超過平均傳輸速率的2%，限制效果較為精準(zhǔn)。

3.3 容器共享空閑帶寬

前面提到，參數(shù)rate設(shè)置了容器的上限帶寬，若同時設(shè)置參數(shù)ceil（大于等于rate的一個值），則在父分類有空閑帶寬時，會實際達(dá)到不超過ceil值的帶寬利用。為測試容器共享空閑帶寬的情況，啟動一個容器后，并建立兩個子分類，其中子分類1的參數(shù)設(shè)置為rate=20Mb/s，ceil=20Mb/s，即嚴(yán)格限制帶寬為20Mb/s;子分類2的參數(shù)設(shè)置為rate=50Mb/s，ceil=50Mb/s。同樣在10s的時間間隔內(nèi)，每0.5s打印該時段內(nèi)傳輸字節(jié)量以及平均的傳輸速率，作為參考基準(zhǔn)。

重新啟動一個容器，建立兩個子分類，其中：子分類1的參數(shù)設(shè)置為rate=20Mb/s，ceil=120Mb/s（大于容器的總帶寬）;子分類2的參數(shù)設(shè)置為rate=50Mb/s，ceil=120Mb/s。兩次實驗結(jié)果如圖5所示。

從圖5中可知，在設(shè)置ceil為一個較大參數(shù)的情況下，容器中的子分類會利用空閑帶寬，并且在默認(rèn)優(yōu)先級的情況下，幾乎等額分配空閑帶寬。圖中rate=ceil=20Mb/s的數(shù)據(jù)波動不可忽視，原因在于：每個0.5s的時間段內(nèi)打印的傳輸數(shù)據(jù)并不準(zhǔn)確是這個時間段內(nèi)傳輸?shù)臄?shù)據(jù)，存在上個時間段部分傳輸?shù)臄?shù)據(jù)記錄到這個時間段，而這個時間段內(nèi)部分傳輸?shù)臄?shù)據(jù)被記錄到下一個時間段內(nèi)的情況，因此數(shù)據(jù)并不準(zhǔn)確維持在20Mb/s而略有波動，但總體還是在20Mb/s附近。實驗10s的總時間段內(nèi)平均傳輸速率為20.1Mb/s，誤差約為0.5%，與設(shè)置數(shù)據(jù)精準(zhǔn)符合，故上述波動認(rèn)為是可接受的。

當(dāng)利用空閑帶寬時，測試數(shù)據(jù)波動幅度增大，符合預(yù)期。當(dāng)rate=50Mb/s，ceil大于總帶寬，在測試的最后時段數(shù)據(jù)有明顯較大的增幅，原因在于：啟動容器并建立子分類的過程中，由于是手動設(shè)置參數(shù)并開始進(jìn)程，因此兩個子分類有可觀的時間先后差。在該數(shù)據(jù)的最后兩個測試時間點，rate=20Mb/s的子分類已結(jié)束進(jìn)程，釋放了帶寬空間，容器中有了更多的空閑帶寬，因此該子分類的傳輸速率迅速增大。

3.4 容器優(yōu)先級設(shè)定

為了測試優(yōu)先級（即參數(shù)prio）對數(shù)據(jù)傳輸速率的影響，對容器中的兩個子分類配置如下參數(shù)：子分類1中rate=20Mb/s，prio=1;子分類2中rate=50Mb/s，prio=3。其中ceil設(shè)置為120Mb/s（大于容器總帶寬），同樣在10s的時間間隔內(nèi)，每0.5s打印該時段內(nèi)傳輸字節(jié)量以及平均的傳輸速率。將該數(shù)據(jù)與3.2節(jié)中得到的參考基準(zhǔn)數(shù)據(jù)對比，結(jié)果如圖6所示。

參數(shù)值越小優(yōu)先級越高，優(yōu)先級高的分類數(shù)據(jù)包將被優(yōu)先發(fā)送。在圖6中，即rate=20Mb/s、prio=1的子分類優(yōu)先級更高，在容器有空閑帶寬的情況下，占滿了空閑帶寬，而優(yōu)先級較低（prio=3）的子分類僅使用了保證的50Mb/s帶寬。

在測試的最后時段，優(yōu)先級更高的子分類先結(jié)束進(jìn)程（由于手動設(shè)置而導(dǎo)致兩個子分類開始進(jìn)程的時刻存在時間差），優(yōu)先級低的子分類開始使用容器內(nèi)的空閑帶寬，因此子分類2（rate=50Mb/s、prio=3）的傳輸速率在最后略有提升。

4 結(jié)語

Docker并沒有給出網(wǎng)絡(luò)限制的方案，因為目前網(wǎng)絡(luò)是通過插件來實現(xiàn)的，和容器本身的功能相對獨立，不容易實現(xiàn)，擴(kuò)展性也很差。Docker社區(qū)已經(jīng)有很多呼聲并且有很多關(guān)于添加網(wǎng)絡(luò)帶寬限制的提議，騰訊的Docker云平臺GaiaStack也探索了一些對網(wǎng)絡(luò)資源進(jìn)行限制的方法。

本文系統(tǒng)基于CGroups文件系統(tǒng)實時監(jiān)測機(jī)制，利用內(nèi)核CGroups系統(tǒng)實現(xiàn)的VFS文件系統(tǒng)作為媒介，將Docker容器創(chuàng)建時設(shè)置的網(wǎng)絡(luò)控制參數(shù)傳遞給TC，進(jìn)而控制TC實現(xiàn)具體的網(wǎng)絡(luò)控制。經(jīng)測試可知，本文的系統(tǒng)對于網(wǎng)絡(luò)帶寬的限制可以達(dá)到精準(zhǔn)的控制，還可以對容器任務(wù)定義優(yōu)先級，在保證其他容器帶寬的前提下，優(yōu)先分配空閑帶寬給優(yōu)先級高的容器，保證優(yōu)先級高的分類數(shù)據(jù)包被優(yōu)先發(fā)送。但Docker中其他資源的限制都是在內(nèi)核層面實現(xiàn)的，因此本文的系統(tǒng)沒有從內(nèi)核的本質(zhì)上解決網(wǎng)絡(luò)限制的問題，未來將在內(nèi)核層面作更深入的研究。

參考文獻(xiàn) （References）

[1]BOETTIGER C. An introduction to docker for reproducible research， with examples from the renvironment [J]. ACM SIGOPS Operating Systems Review， 2015， 49（1）： 71-79.

[2]王亞玲，李春陽，崔蔚，等.基于Docker的PaaS平臺建設(shè)[J].計算機(jī)系統(tǒng)應(yīng)用，2016，25（3）：72-77.（WANG Y L， LI C Y， CUI W， et al. Construction of Docker-based PaaS [J]. Computer Systems & Applications， 2016， 25（3）： 72-77.）

[3]BERNSTEIN D. Containers and cloud： from LXC to Docker to Kubernetes [J]. IEEE Cloud Computing， 2014， 1（3）： 81-84.

[4]LIU D， ZHAO L. The research and implementation of cloud computing platform based on Docker [C]// Proceedings of the 11th International Computer Conference on Wavelet Active Media Technology and Information Processing. Piscataway： IEEE， 2014： 475-478.

[5]KAN C. DoCloud： an elastic cloud platform for Web applications based on Docker [C]// Proceedings of the 18th International Conference on Advanced Communication Technology. Piscataway： IEEE， 2016： 478-483.

[6]ISMAIL B I， GOORTANI E M， AB KARIM M B， et al. Evaluation of Docker as edge computing platform [C]// Proceedings of the 2015 IEEE Conference on Open Systems. Piscataway： IEEE， 2015： 130-135.

[7]ABDELBAKY M， DIAZ-MONTES J， PARASHAR M， et al. Docker containers across multiple clouds and data centers [C]// Proceedings of the 2015 IEEE/ACM 8th International Conference on Utility and Cloud Computing. Piscataway： IEEE， 2015： 368-371.

[8]BELLAVISTA P， ZANNI A. Feasibility of fog computing deployment based on Docker containerization over RaspberryPi [C]// Proceedings of the 18th International Conference on Distributed Computing and Networking. New York： ACM， 2017： Article No. 16.

[9]CHUNG M T， QUANG-HUNG N， NGUYEN M T， et al. Using Docker in high performance computing applications [C]// Proceedings of the 2016 IEEE 6th International Conference on Communications and Electronics. Piscataway： IEEE， 2016： 52-57.

[10]LIU Q， ZHENG W， ZHANG M， et al. Docker-based automatic deployment for nuclear fusion experimental data archive cluster [J]. IEEE Transactions on Plasma Science， 2018， 46（5）： 1281-1284.

[11]XIE B， SUN G， MA G. Docker based overlay network performance evaluation in large scale streaming system [C]// Proceedings of the 2016 IEEE Advanced Information Management， Communicates， Electronic and Automation Control Conference. Piscataway： IEEE， 2016： 366-369.

[12]ZHENG Z， WU X， ZHANG Y， et al. QoS ranking prediction for cloud services [J]. IEEE Transactions on Parallel and Distributed Systems， 2013， 24（6）： 1213-1222.

[13]KHALID J， ROZNER E， FELTER W， et al. Iron： isolating network-based CPU in container environments [C]// Proceedings of the 15th USENIX Symposium on Networked Systems Design and Implementation. Berkeley， CA： USENIX Association， 2018： 313-328.[EB/OL]. [2019-03-20]. https：//www.usenix.org/system/files/conference/nsdi18/nsdi18-khalid.pdf.

[14]龍恒.Linux流控工具TC的原理及實用案例分析[J].計算機(jī)與現(xiàn)代化，2010（11）：80-84，88.（LONG H. TC principle of Linux traffic control tool and its practical case analysis [J]. Computer and Modernization， 2010（11）： 80-84， 88.）

[15]李曉利，郭宇春.QoS技術(shù)中令牌桶算法實現(xiàn)方式比較[J].中興通訊技術(shù)，2007，13（3）：56-60.（LI X L， GUO Y C. Comparison between token bucket algorithms in QoS technology [J]. ZTE Communications， 2007， 13（3）： 56-60.）

This work is partially supported by the National Natural Science Foundation of China （61170306）， the Hubei Province Key Laboratory of Intelligent Information Processing and Real-time Industrial System （znxx2018MS05）.

WANG Zhiwei， born in 1982， M. S. candidate. His research interests include information security.

YANG Chao， born in 1982， Ph. D.， associate professor. His research interests include information security.

收稿日期：2019-05-06;修回日期：2019-07-12;錄用日期：2019-07-19。

基金項目：國家自然科學(xué)基金資助項目（61170306）;智能信息處理與實時工業(yè)系統(tǒng)湖北省重點實驗室開放基金資助項目（znxx2018MS05）。

作者簡介：王志偉（1982—），男，北京人，碩士研究生，主要研究方向：信息安全; 楊超（1982—），男，湖北武漢人，副教授，博士，CCF會員（會員編號：94791M），主要研究方向：信息安全。

文章編號：1001-9081（2019）12-3628-05DOI：10.11772/j.issn.1001-9081.2019040765