背景在我之前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地址網段對二層網絡規模的限制，打造出一個大二層的網絡。