[[185933]]

容器網(wǎng)絡(luò)背景

如果只是在一臺(tái)機(jī)器上使用Docker，或許你基本不用關(guān)心網(wǎng)絡(luò)配置，因?yàn)镈ocker Daemon默認(rèn)模式還是比較友好的，直接幫你們生一個(gè)Bridge命名為Bridge0，這樣你可以通過端口映射的模式或是主機(jī)模式就可以讓容器與外部互聯(lián)互通了，而不用使用任何網(wǎng)絡(luò)工具(brctl, iptables)手工創(chuàng)建。但是如果將容器放到一個(gè)集群環(huán)境中(如使用Mesos或者K8S編排工具)，這個(gè)網(wǎng)絡(luò)問題就比較痛苦了。因?yàn)樾枰ＷC如何暴露容器給外部訪問，同時(shí)又沒有過多的額外性能開銷，網(wǎng)絡(luò)方案又是比較可控穩(wěn)定，這成為了一個(gè)基于容器的PaaS平臺(tái)的成功的關(guān)鍵因素。

我們的需求:獨(dú)立IP

除了網(wǎng)絡(luò)性能和網(wǎng)絡(luò)穩(wěn)定性的問題需要考量外，我們內(nèi)部有個(gè)很重要的要求就是一定要確保每個(gè)容器獲得一個(gè)獨(dú)立的IP，并且確保每個(gè)容器間可以相互訪問。因?yàn)槲覀冇凶约旱幕赗PC的服務(wù)化體系，需要一個(gè)平面的通訊網(wǎng)絡(luò)，并且關(guān)聯(lián)系統(tǒng)如APM系統(tǒng)，都是依賴這個(gè)獨(dú)立IP做分析的。

網(wǎng)絡(luò)方案選型

***次做容器化的架構(gòu)(半年前)，選擇網(wǎng)絡(luò)方案的要點(diǎn)是簡單和成熟的方案。網(wǎng)絡(luò)選型主要有兩個(gè)大方向，一個(gè)是物理機(jī)器方案即通過交換機(jī)的方式做方案如VLAN模式，VxLan模式等。另一個(gè)是軟件方案SDN，如Overlay網(wǎng)絡(luò)等。因?yàn)槭俏覀?**次做容器方案，為了保險(xiǎn)起見，我們更信任物理設(shè)備的方式，所以我們選擇了VLAN的模式作為***次選擇，而VxLan對(duì)于物理設(shè)備有要求，先暫時(shí)放棄。不過如果有硬件基礎(chǔ)的，則可以有限考慮VxLan方式。

***版的VLAN網(wǎng)絡(luò)方案

對(duì)于使用VLAN的模式，一開始我們都沒有找到合適的資料，都是自己摸索出來的，后來新版本的docker支持docker network命令后，這些就簡單一些。而我們是無需用docker create network的。主要方案如下：

"vlan mode"

***版方案的缺陷

從***版的方案上看，雖然簡單而且也比較穩(wěn)定，我們?cè)谏a(chǎn)上跑了4個(gè)多月了，沒有出現(xiàn)過問題。但是從管理監(jiān)控的角度看，這個(gè)方案還是有明顯的缺陷，只是在容器規(guī)模還沒有達(dá)到一定的量的時(shí)候，這個(gè)缺陷是可以忍受的。但是對(duì)于這些缺陷，我們?cè)谧鱿乱话娴钠脚_(tái)的時(shí)候就需要尋找合適的解決方案了。

這些缺陷主要是：

• 一臺(tái)主機(jī)上使用的IP數(shù)量被固定了，因?yàn)槲覀兪菍P段分配給了docker daemon，這樣會(huì)存在一個(gè)風(fēng)險(xiǎn)如果機(jī)器資源還有剩余，mesos+marathon就會(huì)在該主機(jī)上啟動(dòng)容器，但是有可能這個(gè)時(shí)候沒有ip了，這樣marathon就會(huì)不停的啟動(dòng)容器銷毀容器。
• 在容器數(shù)量比較多的時(shí)候，二級(jí)平面網(wǎng)絡(luò)的容器部署，在每個(gè)容器的新創(chuàng)建都會(huì)廣播ARP包，這樣整個(gè)網(wǎng)絡(luò)的風(fēng)暴比較厲害。當(dāng)然在容器數(shù)量規(guī)模還未起來的時(shí)候，這個(gè)可以暫時(shí)忽略。特別是對(duì)于動(dòng)態(tài)伸縮容器的場景比較小的時(shí)候，這個(gè)問題并不大。不過通過和京東的永成大神聊過后，有個(gè)workaround的方式繞開這個(gè)問題，后面會(huì)講。
• 主要問題在于核心交換機(jī)的mac-ip的這個(gè)表的容量，因?yàn)槿萜鞔蚱屏嗽瓉淼奈锢頇C(jī)體系，讓核心交換機(jī)來處理容器的mac-ip的關(guān)系，這個(gè)對(duì)于傳統(tǒng)的交換機(jī)并不合適。不過本人對(duì)于網(wǎng)絡(luò)設(shè)備只是略知一二，所以，這個(gè)問題只是聽說的程度。如果有不對(duì)，請(qǐng)指出。

第二版的VLAN網(wǎng)絡(luò)方案

第二版網(wǎng)絡(luò)需求

• 在確保容器能夠有一個(gè)獨(dú)立的IP的同時(shí)，不再限制單一主機(jī)的IP的數(shù)量，支持更多資源需求小的服務(wù)應(yīng)用的部署。
• 能夠限制單個(gè)容器的對(duì)于網(wǎng)卡的使用，避免因?yàn)槟硞€(gè)容器的網(wǎng)絡(luò)的使用突然過大，影響同主機(jī)的其它容器的使用。
• 減緩因?yàn)槿萜鲃?dòng)態(tài)伸縮帶來的網(wǎng)絡(luò)ARP風(fēng)暴的影響

動(dòng)態(tài)IP管理方案

對(duì)于要使容器有獨(dú)立的IP，又要使每個(gè)主機(jī)的IP的管理動(dòng)態(tài)化，那么就需要將IP分配放在docker daemon/mesos+marathon的外部管理，通過插件plugin的方式集成。目前可選的方式是docker daemon的IPAM接口，或者是mesos slave的IPAM接口。雖然都叫IPAM，但是他們基于的機(jī)制不同。

Docker的IPAM(IP address management)是在Docker daemon的CNM(Container Network Model)機(jī)制下的IP管理驅(qū)動(dòng)。CNM的設(shè)計(jì)模型，可以參考CNM Design。 Docker IPAM可以參考Docker IPAM

而對(duì)于Mesos則是遵循CNI的規(guī)范。CNI規(guī)范可以參看CNI Spec。

不過對(duì)于只需要?jiǎng)討B(tài)管理IP地址的話，基于任何一種IPAM的接口都是可以的。所以我們經(jīng)過老肖(@熟人云)介紹，參考了Talking Data公司的Shrike來做動(dòng)態(tài)的IP管理。Shrike是基于Docker deamon的IPAM的方案， 所以只能用于基于Docker容器的方案，如果是用mesos unified container，則需要自己去改造成對(duì)接CNI的IPAM的接口。

雖然Shrike比較簡單，但是目前Shrike有些局限，所以我們需要在上面做一些改造，以支持后續(xù)的擴(kuò)展。主要包括：

• Shrike這個(gè)進(jìn)程如果意外退出，IP的釋放消息(Release address)未被處理，就會(huì)造成IP被***占用。目前我們的思路是，在shrike啟動(dòng)的時(shí)候主動(dòng)去掃描本機(jī)的docker container，然后和etcd上的數(shù)據(jù)比對(duì)，如果有IP沒有被釋放，則主動(dòng)清理。
• 對(duì)于上面這個(gè)約束，我們需要改造Etcd中數(shù)據(jù)結(jié)構(gòu)，以支持將主機(jī)IP存入etcd中，便于后續(xù)的主動(dòng)清理。同時(shí)改造etcd數(shù)據(jù)結(jié)構(gòu)也是為了限流使用。

網(wǎng)絡(luò)限流方案

對(duì)于網(wǎng)絡(luò)限流，一開始的思路是想利用mesos+marathon方案的自定義資源管理的方式，但是因?yàn)閙arathon遲遲不支持自定義資源調(diào)度，所以這個(gè)方式暫時(shí)放下了。希望用這樣的方式管理的原因是想把網(wǎng)卡變成類似cpu/mem的資源同等對(duì)待，只要分配了帶寬給容器的綜合超過一定數(shù)就不再這個(gè)主機(jī)啟動(dòng)容器了。Mesos的自定義資源參考mesos attr resource

在這里還是要吐槽一下Marathon，開發(fā)的進(jìn)度和Mesos太不一致了，希望Mesosphere的同學(xué)好好push一下。

這條路暫時(shí)走不通，那么在用Shrike做動(dòng)態(tài)IP分配的時(shí)候，我想能不能在IP動(dòng)態(tài)分配的時(shí)候就同時(shí)做了這個(gè)容器的帶寬限制呢?所以就有了以下方案

"shrike"

主要的流程如下：

• 在Shrike中增加一個(gè)Throttling的模塊，Shrike動(dòng)態(tài)分配IP后發(fā)送一條消息給這個(gè)Throttlilng模塊，包含容器ip信息(可惜沒有容器的id)
• Throttling模塊收到消息后，調(diào)用docker daemon接口查詢這個(gè)ip對(duì)應(yīng)的容器在主機(jī)的網(wǎng)絡(luò)名稱(這里可以用unix socket接口或者h(yuǎn)ttp接口，因?yàn)槭潜緳C(jī)調(diào)用)
• 查詢這個(gè)容器的環(huán)境變量如net_in, net_out的值(這個(gè)目前是啟動(dòng)容器的時(shí)候配置上去的)
• 通過調(diào)用linux下的wondershape工具來對(duì)容器進(jìn)行限制帶寬

這個(gè)方案還有后續(xù)幾個(gè)事宜我們還沒有處理的：

• 如何發(fā)布Shrike，目前的思路是在安裝物理機(jī)的時(shí)候一并安裝(打成rpm的方式，用systemd方式維護(hù))
• 或許可以嘗試用容器的方式發(fā)布，但是不知道是否可行。

我們還在構(gòu)思，如圖所示提供一個(gè)Console的管理控制臺(tái)，實(shí)時(shí)展示容器的網(wǎng)絡(luò)配置以及使用情況，因?yàn)閚et_id和net_out多會(huì)寫入到Etcd中，所以完全可以在界面直接調(diào)整這兩個(gè)值，然后Throttling的模塊watch到變化就直接執(zhí)行wondershape對(duì)容器進(jìn)行更改就可。

減少ARP廣播包的方案

ARP廣播的目的是確定IP所在的主機(jī)的MAC地址，用于二層網(wǎng)絡(luò)的尋址。但是容器的創(chuàng)建的時(shí)候，通常MAC地址是通過一定的規(guī)則生成的，所以每次有容器啟動(dòng)，都會(huì)廣播這個(gè)MAC地址和它的IP的對(duì)應(yīng)關(guān)系。但是如果MAC-IP的對(duì)應(yīng)關(guān)系建立后沒有關(guān)變，則ARP是無需再次廣播的。這是通俗的說法。具體可以看RFC826規(guī)范。

既然是這樣，我們是否可以找到一種手段來控制ARP包的量呢?有的，就是預(yù)先設(shè)置好IP-MAC的關(guān)系，也就是只要IP相同，它的MAC地址就是相同的。所以對(duì)于容器方案，可以預(yù)先初始化好規(guī)劃的容量的所有IP和MAC的對(duì)應(yīng)關(guān)系。然后每個(gè)容器啟動(dòng)時(shí)主動(dòng)的去拉取這個(gè)表，并通過arp命令設(shè)置到容器中。(這里有個(gè)細(xì)節(jié)沒有去實(shí)驗(yàn)，就是如果有幾萬個(gè)容器，arp命令執(zhí)行這個(gè)表的時(shí)間是多少，是否影響容器啟動(dòng)的時(shí)間?)

這樣容器啟動(dòng)后就有所有容器的IP-MAC對(duì)應(yīng)關(guān)系，就無需發(fā)送過多的ARP包了。 不過這里還有另外一個(gè)問題，那就是無法使用IPAM接口，因?yàn)镮PAM接口沒有提供對(duì)應(yīng)的容器的MAC的指定手段。(看CNI的源碼歷史，MAC設(shè)置原來是可以在IPAM中設(shè)置的，但是后來被挪到外層了)

所以如果需要在容器啟動(dòng)后直接更新一個(gè)大的固定的IP-MAC列表，就只能通過CNM/CNI的接口方式設(shè)置IP和MAC地址了

核心交換機(jī)的MAC地址的承載能力方案

這個(gè)只能是找硬件廠商解決了。據(jù)說京東下一代的方案是直接定制核心交換機(jī)以支持容器方案。具體細(xì)節(jié)不太清楚。如果有更好的方案，請(qǐng)記得告訴我

小結(jié)

到此為止，基本就涵蓋我們第二版的網(wǎng)絡(luò)改進(jìn)方案的大體思路了。或許你會(huì)問，怎么不考慮用現(xiàn)在熱門的幾個(gè)三層網(wǎng)絡(luò)方案呢?其實(shí)理由很簡單，就是還是不能完全掌握的了，特別是如果問題定位，如何調(diào)試都是比較困難的。但是依賴與硬件交換機(jī)和Linux的特性，這個(gè)還是比較有信心的。所以建議如果不是技術(shù)有足夠的掌控力，不要輕易嘗試SDN的方案，除非你買專業(yè)的技術(shù)服務(wù)。

【本文是51CTO專欄作者“VIPDOCKER-了哥 ”的原創(chuàng)文章，如需轉(zhuǎn)載請(qǐng)通過51CTO與作者聯(lián)系】

戳這里，看該作者更多好文