多层嵌套的网络方案，一方面浪费了大量计算资源来处理网络流量；同时又导致一些旧的网络监控设备无法透明的监控网络流量。
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 的文章
