[[139089]]

背景

在我之前weave的運(yùn)行原理的文章中，介紹到 weave在跨主機(jī)的容器通信過程中，會使用pcap截獲容器發(fā)送和接收的 網(wǎng)絡(luò)包，然后按照自定義的格式將這些包重新封裝為UDP報(bào)文再次注入到bridge上的接口發(fā)送出去。實(shí)際上這不是weave獨(dú)有的選擇，CoreOS的 fannel網(wǎng)絡(luò)項(xiàng)目也是一樣的方法。最近被docker公司收購的初創(chuàng)項(xiàng)目socketplane，采用基于openvswitch的vxlan的隧道技術(shù)來實(shí)現(xiàn)相同的過程。那么，就有一個(gè)疑問：實(shí)際上只要使用主機(jī)port mapping或是將docker原生網(wǎng)橋docker0的上行鏈路連通網(wǎng)卡，容器的流量都可以從主機(jī)發(fā)送出去，為什么這么多的docker網(wǎng)絡(luò)項(xiàng)目都不約而同地選擇使用隧道技術(shù)將網(wǎng)絡(luò)負(fù)載再次封裝發(fā)送，接收的時(shí)候再解封裝呢?

解析原因

隧道封裝是目前最簡單的穿透docker容器復(fù)雜網(wǎng)絡(luò)環(huán)境安全設(shè)置的方法

實(shí)際上這個(gè)問題最重要的原因是與docker容器運(yùn)行環(huán)境的多樣復(fù)雜性是直接相關(guān)的。我們都知道docker容器可以運(yùn)行在公有云、私有云、虛擬化以及裸機(jī)上。為了網(wǎng)絡(luò)的安全，這些環(huán)境上都應(yīng)該有嚴(yán)格的安全組和防火墻設(shè)置來保障只有合法流量能夠通過端口。這些帶來了網(wǎng)絡(luò)安全的同時(shí)，也給docker 容器的部署和可移動性帶來了麻煩。每次部署啟動一個(gè)容器，就要將其相應(yīng)使用的端口上的安全設(shè)置更新為開放。尤其是混合云場景下這個(gè)問題就更為麻煩了。我舉一個(gè)具體的例子：當(dāng)前很多的PaaS服務(wù)提供商都沒有自己的數(shù)據(jù)中心，他們直接從公有云的IaaS提供商那里獲得虛擬機(jī)，那么這個(gè)時(shí)候就需要PaaS提供方調(diào)用公有云IaaS提供方的網(wǎng)絡(luò)安全設(shè)置的API來打開端口。PaaS提供商是不會把自己綁定死的，會選擇多家公有云的 IaaS(AWS，GCE，Azure等)，這些IaaS提供商的API全都不一樣，這得多麻煩啊。這還沒有考慮私有云，自己數(shù)據(jù)中心的虛擬化和裸機(jī)環(huán)境的端口ACL設(shè)置的復(fù)雜。

網(wǎng)絡(luò)安全的設(shè)置還不僅僅只有這些，比如最常見的ip與mac綁定，這是openstack的默認(rèn)設(shè)置，要修改可以，同樣也要調(diào)用openstack neutron的API增加端口允許的ip-mac pair。這里額外提一下，docker主機(jī)的port mapping方式由于限制了容器移動后的可訪問性，不被大多數(shù)跨主機(jī)docker網(wǎng)絡(luò)項(xiàng)目采用，多數(shù)項(xiàng)目還是希望能給每個(gè)容器一個(gè)ip，容器間訪問使用這個(gè)ip，而不是docker容器所在主機(jī)的ip。

結(jié)論

通過上面的解析，可以想象，如果是在混合云場景下，使用隧道封裝技術(shù)后，從虛擬機(jī)流出的流量ip和mac都是***的，且只使用固定的端口，那docker容器運(yùn)行環(huán)境的安全設(shè)置就可以固定下來，簡便多了。

其實(shí)，docker網(wǎng)絡(luò)中使用隧道封裝技術(shù)還可以有利于一些其他問題的解決：

1. 容器相較于虛擬機(jī)在一臺主機(jī)上的密度大大增加，至少多出一個(gè)量級，要說兩個(gè)量級我也信。在這樣的情況下機(jī)架上的接入交換機(jī)的port-mac表容量是否足夠呢，這里使用了隧道封裝了負(fù)載后，就不用擔(dān)心這個(gè)問題了。

2. 此外，就如同虛擬機(jī)使用了vxlan后一樣，有利于打破ip地址網(wǎng)段對二層網(wǎng)絡(luò)規(guī)模的限制，打造出一個(gè)大二層的網(wǎng)絡(luò)。

原文鏈接：http://www.51gocloud.com/?p=1327