背景
在我之前weave的運作原理的文章中，介紹到 weave在跨主機的容器通信過程中，會使用pcap截獲容器發送和接收的 網絡包，然後按照自定義的格式将這些包重新封裝為udp封包再次注入到bridge上的接口發送出去。實際上這不是weave獨有的選擇，coreos的 fannel網絡項目也是一樣的方法。最近被docker公司收購的初創項目socketplane，采用基于openvswitch的vxlan的隧道技術來實作相同的過程。那麼，就有一個疑問：實際上隻要使用主機port mapping或是将docker原生網橋docker0的上行鍊路連通網卡，容器的流量都可以從主機發送出去，為什麼這麼多的docker網絡項目都不約而同地選擇使用隧道技術将網絡負載再次封裝發送，接收的時候再解封裝呢?
解析原因
隧道封裝是目前最簡單的穿透docker容器複雜網絡環境安全設定的方法
實際上這個問題最重要的原因是與docker容器運作環境的多樣複雜性是直接相關的。我們都知道docker容器可以運作在公有雲、私有雲、虛拟化以及裸機上。為了網絡的安全，這些環境上都應該有嚴格的安全組和防火牆設定來保障隻有合法流量能夠通過端口。這些帶來了網絡安全的同時，也給docker 容器的部署和可移動性帶來了麻煩。每次部署啟動一個容器，就要将其相應使用的端口上的安全設定更新為開放。尤其是混合雲場景下這個問題就更為麻煩了。我舉一個具體的例子：目前很多的paas服務提供商都沒有自己的資料中心，他們直接從公有雲的iaas提供商那裡獲得虛拟機，那麼這個時候就需要paas提供方調用公有雲iaas提供方的網絡安全設定的api來打開端口。paas提供商是不會把自己綁定死的，會選擇多家公有雲的 iaas(aws，gce，azure等)，這些iaas提供商的api全都不一樣，這得多麻煩啊。這還沒有考慮私有雲，自己資料中心的虛拟化和裸機環境的端口acl設定的複雜。
網絡安全的設定還不僅僅隻有這些，比如最常見的ip與mac綁定，這是openstack的預設設定，要修改可以，同樣也要調用openstack neutron的api增加端口允許的ip-mac pair。這裡額外提一下，docker主機的port mapping方式由于限制了容器移動後的可通路性，不被大多數跨主機docker網絡項目采用，多數項目還是希望能給每個容器一個ip，容器間通路使用這個ip，而不是docker容器所在主機的ip。
結論
通過上面的解析，可以想象，如果是在混合雲場景下，使用隧道封裝技術後，從虛拟機流出的流量ip和mac都是唯一的，且隻使用固定的端口，那docker容器運作環境的安全設定就可以固定下來，簡便多了。
其實，docker網絡中使用隧道封裝技術還可以有利于一些其他問題的解決：
1. 容器相較于虛拟機在一台主機上的密度大大增加，至少多出一個量級，要說兩個量級我也信。在這樣的情況下機架上的接入交換機的port-mac表容量是否足夠呢，這裡使用了隧道封裝了負載後，就不用擔心這個問題了。
2. 此外，就如同虛拟機使用了vxlan後一樣，有利于打破ip位址網段對二層網絡規模的限制，打造出一個大二層的網絡。
本文作者：佚名
來源：51cto