多層嵌套的網絡方案，一方面浪費了大量計算資源來處理網絡流量；同時又導致一些舊的網絡監控設備無法透明的監控網絡流量。
1.網絡轉發效率
從兩個方面分別來分析：
Rancher的原生網絡是使用基於IPSec的overlay VPN技術，由於跨主機的容器之間的流量都需要經過IPSec解封包，因此性能方面有待改善。
Openstack的網絡性能受到所使用的網絡解決方案的影響。如果使用基於SDN的硬件解決方案來offload流量到外部設備做報文的解封包，這樣尚且能夠忍受內部容器網絡的overlay方案。一旦使用普通的openVswitch，使用軟件來解封包，浙江浪費很多的CPU資源來處理報文。
2. 流量監控的需求
金融客戶大部分都有自己網絡監控工具，這些工具一般能夠解封常規的報文，較難處理IPSec加密的報文。為了保障網絡對於安全監控的透明性，網絡內部嚴禁使用Overlay VPN的解決方案。
因此，如何在基於openstack的IaaS上層運行Rancher管理平臺，就成為亟待解決的問題。
要實現容器在openstack網絡中的扁平化，也就是需要將運行與虛擬機中的容器的端口放到虛擬的層面。網上有一些現成的方案可以達到這一目的，比如MACVLAN， 或者VLAN Trunk等。但是基於Rancher的Metadata server位於其所在宿主機169.254.169.250的這一特殊性，我們最終選用了Bridge的方式來實現。具體如下圖：
為了阻止租戶修改VM的IP或者MAC地址來搞破壞，openstack網絡內部一般不允許虛擬機內部使用其他IP地址來通信，這就會導致容器無法使用自己的IP來與外部通信。為了解決這個問題，我們必須修改虛擬機port的“allow address pair”屬性，並配置上容器所使用的IP地址；同時，在容器遷移或者是銷燬的時候，對應虛擬機port的該屬性又需要被更新。在我們的方案中，通過容器宿主機上的CNI Plugin來觸發對應的操作。
另外，為了實現容器和虛擬機之間的通信，我們在每個VM上綁定兩張網卡。其中一張用來管理VM，另一張用於容器的通信。容器網絡和虛擬機網絡最終在租戶的虛擬路由器上彙集，實現三層可達。同時，虛擬路由器同樣連接外部網絡，通過設置特定的防火牆規則，開放特定IP地址對Openstack管理網絡的訪問，從而保障運行於Rancher內部的wise2c-neutron-controller可以訪問neutron server。
除此之外，在VM內部，為了訪問到綁定到docker0上的metadata server，我們創建了veth-pair來連接br-cni0和docker0。但是這樣的連接必須在數據鏈路層做嚴格的流量控制，除了允許容器網絡側訪問169.254.169.250的流量外，其他流量均不允許通行。
CNI Plugin 主要包含如下功能
創建br-cni0網橋（首次啟動檢測到該主機上不存在該網橋時）
建立br-cni0到docker0的連接，並寫入ebtable規則，保障只有metadata流量可以通信，其他流量禁止
-
掛載container-port到br-cni0網橋
從Rancher IPAM獲取容器的IP和MAC地址，並配置到容器的eth0
使用容器所在主機信息、容器的IP和MAC地址這些參數向Wise2C-Neutron-Controller請求neutron-port
配置容器的路由，並寫入訪問Metadata地址的路由下一跳
Wise2C Neutron Controller主要實現：
啟動後從openstack Neutron讀取所有port，並過濾出容器端口作為緩存
監聽容器port新增和刪除的請求
當收到請求或，將請求轉化為對openstack Neutron的具體操作，創建/刪除port以及更新parent port的“allow address pair”屬性
將核心組件都做成Rancher Catalog後如下圖所示，主要包含Wise2C Flat Network 和 Wise2C Neutron Controller兩個Catalog：
Openstack中的flat-net用於VM Management子網，將vlan_subnet用於Container通信的子網：
使用OpenStack的虛擬機作為Rancher運行的宿主機：
將Rancher環境拉起來後，基礎設施應用列表如下圖所示：
容器能夠通過扁平網絡正常訪問網關，以及位於宿主機上的metadata地址：
閱讀更多 睿雲智合Wise2C 的文章
