基于Openstack的Rancher扁平网络

多层嵌套的网络方案一方面浪费了大量计算资源来处理网络流量,同时又导致一些旧的网络监控设备无法透明的监控网络流量。

需求背景

网络转发效率

从两个方面分别来分析:

  1. Rancher的原生网络是使用基于IPSec的overlay VPN技术,由于跨主机的容器之间的流量都需要经过IPSec解封包,因此性能方面有待改善。
  2. Openstack的网络性能受到所使用的网络解决方案的影响。如果使用基于SDN的硬件解决方案来offload流量到外部设备做报文的解封包,这样尚且能够忍受内部容器网络的overlay方案。一旦使用普通的openVswitch,使用软件来解封包,浙江浪费很多的CPU资源来处理报文。

流量监控的需求

金融客户大部分都有自己网络监控工具,这些工具一般能够解封常规的报文,较难处理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

主要包含如下功能

  1. 创建br-cni0网桥(首次启动检测到该主机上不存在该网桥时)
  2. 建立br-cni0到docker0的连接,并写入ebtable规则,保障只有metadata流量可以通信,其他流量禁止
  3. 挂载container-port到br-cni0网桥
  4. 从Rancher IPAM获取容器的IP和MAC地址,并配置到容器的eth0
  5. 使用容器所在主机信息、容器的IP和MAC地址这些参数向Wise2C-Neutron-Controller请求neutron-port
  6. 配置容器的路由,并写入访问Metadata地址的路由下一跳

Neutron Controller

  1. 启动后从openstack Neutron读取所有port,并过滤出容器端口作为缓存
  2. 监听容器port新增和删除的请求
  3. 当收到请求或,将请求转化为对openstack Neutron的具体操作,创建/删除port以及更新parent port的“allow address pair”属性
0%