張青，劉劍，朱曉民

（1 北京郵電大學(xué)網(wǎng)絡(luò)與交換技術(shù)國家重點(diǎn)實(shí)驗(yàn)室，北京 100876; 2 東信北郵信息技術(shù)有限公司，北京 100191)

1 引言

云計算產(chǎn)業(yè)正處在高速發(fā)展的時期，各種新技術(shù)層出不窮，Docker就是這樣一款顛覆性的產(chǎn)品。云計算的服務(wù)模型大致分為3類，分別為軟件即服務(wù)（SaaS）、平臺即服務(wù)（PaaS）和基礎(chǔ)設(shè)施即服務(wù)（IaaS），正是Docker的出現(xiàn)讓PaaS受到了極大的關(guān)注，也很大程度上引領(lǐng)了PaaS的架構(gòu)走向。

Docker是一款類似于LXC（Linux Containers，Linux容器）的開源應(yīng)用容器引擎，它的輕量、快速和強(qiáng)大的可移植性吸引了眾多的開發(fā)者，并逐漸成為了PaaS容器的主流。Docker使用鏡像技術(shù)實(shí)現(xiàn)了其高可移植性，開發(fā)者將他們的應(yīng)用和全部的環(huán)境依賴打包成一個鏡像，這個鏡像可以被發(fā)布到任何一臺安裝了Docker的機(jī)器上，并運(yùn)行起來成為容器，向外提供服務(wù)。最重要的是,鏡像不依賴于任何語言、框架或系統(tǒng)，獨(dú)立成為一個運(yùn)行單元，根本上解決了云計算中復(fù)雜的環(huán)境依賴關(guān)系。

Docker容器使用沙箱機(jī)制在機(jī)器上創(chuàng)建出了一個獨(dú)立的空間，即使處于同一臺機(jī)器，不同的容器之間也是相互隔離的，它們之間的通信只能像兩臺機(jī)器一樣通過網(wǎng)絡(luò)互訪問來實(shí)現(xiàn)，這樣保證了應(yīng)用之間不會互相干擾。然而現(xiàn)在的應(yīng)用越來越復(fù)雜，不可能只是運(yùn)行在一個容器中，而是多個容器相互協(xié)作來實(shí)現(xiàn)應(yīng)用的功能，這樣容器與容器之間的網(wǎng)絡(luò)互訪問至關(guān)重要。

然而，Docker容器本身的網(wǎng)絡(luò)結(jié)構(gòu)導(dǎo)致實(shí)現(xiàn)網(wǎng)絡(luò)互聯(lián)較為困難。根據(jù)Docker主機(jī)通過端口號來標(biāo)識服務(wù)的特點(diǎn)，業(yè)界通過服務(wù)發(fā)現(xiàn)的方式實(shí)現(xiàn)了容器的編排和整合，取得了不錯的效果，但是這并不完美，所以開源社區(qū)開始探索基于SDN（Software Defined Network，軟件定義網(wǎng)絡(luò)）的網(wǎng)絡(luò)解決方案，覆蓋網(wǎng)絡(luò)成為關(guān)注點(diǎn)之一。

覆蓋網(wǎng)絡(luò)的宗旨是在已有網(wǎng)絡(luò)的基礎(chǔ)上新建一層虛擬網(wǎng)絡(luò)，它旨在跨越不同機(jī)器，讓同一個應(yīng)用下的各個容器處于同一個虛擬鏈路中，從而解決Docker容器的網(wǎng)絡(luò)問題。本文提出了一種覆蓋網(wǎng)絡(luò)的搭建方式，并且具有很好的可伸縮性。

2 Docker網(wǎng)絡(luò)結(jié)構(gòu)

2.1 Docker網(wǎng)絡(luò)

圖1 Docker網(wǎng)絡(luò)結(jié)構(gòu)

圖1展示了Docker的內(nèi)部網(wǎng)絡(luò)結(jié)構(gòu)，多個container通過網(wǎng)橋docker0連接在了一起，構(gòu)成一個內(nèi)部網(wǎng)絡(luò)，每個container都是一個獨(dú)立運(yùn)行的個體，都具有自己的MAC地址和IP地址，此時兩個container可以暢通無阻地通信。外部網(wǎng)絡(luò)與container的通信需要依賴Docker主機(jī)的NAT轉(zhuǎn)換，即container中的每個服務(wù)都需要被Docker主機(jī)上的端口標(biāo)識才能被訪問到，這種情況下Docker表現(xiàn)得更像是一個內(nèi)部網(wǎng)絡(luò)。

2.2 多主機(jī)場景

圖2中展示了處于不同主機(jī)上的container之間的互訪問：IP為172.16.25.90的container能夠?qū)ν馓峁┓?wù)，在其主機(jī)上暴露的端口號為3306，即所有到達(dá)192.168.100.5的3306端口的服務(wù)請求都會被轉(zhuǎn)發(fā)到容器中，這樣外部網(wǎng)絡(luò)就可以實(shí)用container內(nèi)部的服務(wù)。如果在另一臺機(jī)器上有一個容器172.19.25.100想要訪問上述服務(wù)，則必須通過地址192.168.100.5:3306來尋址，這樣就需要在容器中配置另一主機(jī)（192.168.100.5）的地址。

圖2 跨主機(jī)訪問容器

這樣的網(wǎng)絡(luò)訪問方式大大地增加了服務(wù)與主機(jī)的耦合程度，將一個主機(jī)的IP地址作為配置寫入容器的鏡像中去顯然不太明智，如果提供服務(wù)的容器發(fā)生故障或者需要轉(zhuǎn)移到別的主機(jī)上運(yùn)行，那么服務(wù)的使用者必須要更新配置，甚至要重新制作鏡像，這是在運(yùn)行環(huán)境下無法忍受的。

一般可以通過服務(wù)發(fā)現(xiàn)的方式來解決云環(huán)境中的服務(wù)變更問題，但在Docker場景下通用的服務(wù)發(fā)現(xiàn)方式也遇到了困難。

圖3中演示了一個失敗的服務(wù)發(fā)現(xiàn)案例，discovery是服務(wù)注冊集群地址，容器在注冊自身服務(wù)的時候會使用自己的IP地址進(jìn)行注冊，生成服務(wù)名，但在另一側(cè)獲取到的服務(wù)地址并不是一個外部地址，所以并不能順利訪問。通用的服務(wù)發(fā)現(xiàn)方案在Docker環(huán)境下需要修改才可以使用，但是這種方法也并沒有從根本上解決不同主機(jī)上container之間的透明訪問難題，然而通過搭建覆蓋網(wǎng)絡(luò)可以讓容器之間通過各自IP地址互相通信，就可以解決這個問題。

圖3 容器訪問失敗

3 面向Docker覆蓋網(wǎng)絡(luò)搭建

3.1 覆蓋網(wǎng)絡(luò)

覆蓋網(wǎng)絡(luò)即在已有的網(wǎng)絡(luò)拓?fù)涞幕A(chǔ)上重疊出一層虛擬網(wǎng)絡(luò)，它避免了改變已有網(wǎng)絡(luò)層結(jié)構(gòu)所帶來的巨大代價，而是從應(yīng)用層上解決網(wǎng)絡(luò)透明性問題。覆蓋網(wǎng)絡(luò)的虛擬鏈路對應(yīng)著一條或多條物理路徑，其網(wǎng)絡(luò)節(jié)點(diǎn)也可以是各種網(wǎng)絡(luò)功能節(jié)點(diǎn)，如路由器、服務(wù)器等。覆蓋網(wǎng)絡(luò)實(shí)際上就是在底層網(wǎng)絡(luò)提供的基本網(wǎng)絡(luò)連接基礎(chǔ)上，在應(yīng)用層上用軟件的方法實(shí)現(xiàn)的一個新的網(wǎng)絡(luò)。比較著名的覆蓋網(wǎng)絡(luò)系統(tǒng)有Spines等。

圖4 Spines網(wǎng)絡(luò)架構(gòu)圖

如圖4所示，Spines是一個源代碼公開的通用覆蓋網(wǎng)絡(luò)系統(tǒng)，由約翰-霍普金斯大學(xué)的分布式網(wǎng)絡(luò)實(shí)驗(yàn)室所建立。Spines分為兩個層次：用戶層和覆蓋網(wǎng)絡(luò)節(jié)點(diǎn)層。用戶程序要使用Spines覆蓋網(wǎng)絡(luò)提供的服務(wù)，首先要連接到最近的節(jié)點(diǎn)，這樣就可以通過Spines覆蓋網(wǎng)絡(luò)向其它的用戶發(fā)送數(shù)據(jù)了。當(dāng)節(jié)點(diǎn)接收到來自用戶或者其他節(jié)點(diǎn)的數(shù)據(jù)時，就選擇適當(dāng)?shù)穆酚赊D(zhuǎn)發(fā)數(shù)據(jù)。經(jīng)過逐跳的傳輸，數(shù)據(jù)到達(dá)目的節(jié)點(diǎn)，目的節(jié)點(diǎn)根據(jù)數(shù)據(jù)分組的端口，把數(shù)據(jù)提交給用戶程序。Spines提供了端到端的可靠傳輸和不可靠傳輸，可靠傳輸使用了類TCP傳輸模式。

顯然在Docker的場景下我們不能照搬Spines的設(shè)計，Spines中用戶層實(shí)際上是應(yīng)用的接口層，是覆蓋網(wǎng)絡(luò)提供的接口API，這與我們使用覆蓋網(wǎng)絡(luò)來保持Docker容器的可移植性與增加網(wǎng)絡(luò)透明性的宗旨相違背，所以并不需要這一層，但是節(jié)點(diǎn)層是需要保留的。

3.2 容器互訪原理

解決不同主機(jī)上容器的互訪問題，讓它們的IP地址互相可見，是搭建覆蓋網(wǎng)絡(luò)的第一步，原理如圖5所示。

圖5 router轉(zhuǎn)發(fā)數(shù)據(jù)分組

箭頭的指向即為在容器172.16.25.90中ping容器172.16.25.101的過程中數(shù)據(jù)分組的流向，其中router容器承擔(dān)了數(shù)據(jù)分組的轉(zhuǎn)發(fā)任務(wù)。數(shù)據(jù)分組的轉(zhuǎn)發(fā)過程中需要克服的難點(diǎn)如下：

（1）以container1（172.16.25.90)向container2 （172.16.25.101)發(fā)送數(shù)據(jù)分組為例，為了屏蔽容器對于網(wǎng)絡(luò)拓?fù)涞母兄?，即兩個容器就像處于同一個虛擬網(wǎng)段一樣通信，這樣的情況下將container1處封裝好的MAC幀送到另一個主機(jī)的網(wǎng)橋下就可以完成任務(wù)，所以需要考慮的是MAC幀的轉(zhuǎn)發(fā)。

（2）將一臺主機(jī)的MAC幀送到另一臺主機(jī)上并不是一件容易的事情，使用隧道可以解決這個問題。所謂隧道就是一種網(wǎng)絡(luò)協(xié)議被封裝到另一個網(wǎng)絡(luò)協(xié)議中以跨過網(wǎng)絡(luò)傳輸，數(shù)據(jù)分組在發(fā)送端被封裝，在接受端被解開，傳輸過程中的中間路由器并不在意被封裝的協(xié)議是什么。在這里顯然需要在router之間使用傳輸層協(xié)議來封裝鏈路層的數(shù)據(jù)分組。

克服了上述兩個難題，數(shù)據(jù)分組就可以在任意兩個容器之間傳輸，但是我們僅僅是完成了端到端之間的聯(lián)通，而并沒有構(gòu)成一個網(wǎng)絡(luò)。

3.3 網(wǎng)絡(luò)拓?fù)?/h3>

本文的宗旨是構(gòu)建一個高度可伸縮的覆蓋網(wǎng)絡(luò)，所以在上述工作的基礎(chǔ)上，需要描繪出路由器router的網(wǎng)絡(luò)拓?fù)浜途S護(hù)網(wǎng)絡(luò)拓?fù)涞膮f(xié)議。

圖6顯示的是5臺Docker主機(jī)構(gòu)成的覆蓋網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，與圖4中的Spines網(wǎng)絡(luò)結(jié)構(gòu)相似。要維護(hù)這個拓?fù)浣Y(jié)構(gòu)，需要兩種協(xié)議，這兩種協(xié)議在Spines中被廣泛使用。

（1）Hello協(xié)議負(fù)責(zé)建立、拆除、檢測和維護(hù)鄰居節(jié)點(diǎn)之間的連接，節(jié)點(diǎn)間要建立連接，首先要向?qū)Ψ桨l(fā)送Hello分組，而且連接建立起來之后，每隔1 s都要向鄰居節(jié)點(diǎn)發(fā)送心跳，以保持聯(lián)系。

（2）State Flood協(xié)議采用“洪泛”的方式來向整個網(wǎng)絡(luò)傳播拓?fù)浣Y(jié)構(gòu)信息，它讓每個節(jié)點(diǎn)知道整個網(wǎng)絡(luò)的結(jié)構(gòu)，這種洪泛法擴(kuò)散拓?fù)湫畔⒌姆椒ê苋菀自斐删W(wǎng)絡(luò)的擁堵，所以文中覆蓋網(wǎng)絡(luò)不宜過于龐大。

在上文搭建的網(wǎng)絡(luò)拓?fù)渲?，一個數(shù)據(jù)分組的精準(zhǔn)送達(dá)需要有路由算法的支持，Spines也給了兩種選擇：Dijkstra算法和Floyd-Warshall算法，它們都是計算兩點(diǎn)之間最短路徑的算法。

4 結(jié)束語

本文所搭建的覆蓋網(wǎng)絡(luò)將各個主機(jī)上分散的容器聚集到一個虛擬網(wǎng)絡(luò)中，從底層解決了網(wǎng)絡(luò)數(shù)據(jù)分組不可達(dá)的問題，使得Docker容器可以透明地進(jìn)行網(wǎng)絡(luò)編程。它屏蔽了底層的網(wǎng)絡(luò)拓?fù)洌瑢τ谠骗h(huán)境中各種復(fù)雜的網(wǎng)絡(luò)結(jié)構(gòu)有很好的穿透能力。同時本文提出了該網(wǎng)絡(luò)搭建方案的理論可行性，并沒有給出實(shí)踐過程和數(shù)據(jù)，也難免存在一些不足之處，需要在后續(xù)的研究過程中不斷改進(jìn)和創(chuàng)新。

圖6 網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)

[1]SherliaY.Shi, Jonathan S.Turner.Multicast Routing and Bandwidth Dimensioning in Overlay Networks[J].IEEE JSAC, 2002.

[2]The Spines Overlay Network.http://www.spines.org.com, 2010.

[3]李海梅.覆蓋網(wǎng)絡(luò)虛擬鏈路技術(shù)研究[D].浙江：浙江大學(xué)信息與通信工程學(xué)院, 2006.

[4]溫濤, 虞紅芳，李樂民.網(wǎng)絡(luò)虛擬化的過去、現(xiàn)在和未來[J].中興通迅技術(shù), 2014（3).