Rancher技术特性全解及容器网络解决方案(3)

两端主机通过 IPsec 隧道网络通信时,数据包到达物理网卡时,需要通过 Host 内的 Iptables 规则转发到 ipsec 容器内,这个 Iptables 规则管理则是由 network-manager 组件来完成的,https://github.com/rancher/plugin-manager.其原理如下图所示(以?IPsec 为例)：

整体上看 cni ipsec 的实现比之前的 ipsec 精进了不少,而且也做了大量的解耦工作,不单纯是走向社区的标准,之前大量的 Iptables 规则也有了很大的减少,性能上其实也有了很大提升.

3.2 Rancher-net vxlan的实现

那么 rancher-net 的另外一个 backend vxlan 又是如何实现的呢?我们需要创建一套VXLAN网络环境来一探究竟,默认的 Cattle 引擎网络是 IPsec,如果修改成 VXLAN 有很多种方式,可以参考我下面使用的方式.

首先,创建一个新的 Environment Template,把 Rancher IPsec 禁用,同时开启 Rancher VXLAN,如下图所示：

然后,我们创建一个新的 ENV,并使用刚才创建的模版 Cattle-VXLAN,创建完成后,添加 Host 即可使用.如下图所示：

以分析 IPsec 网络实现方式来分析 VXLAN,基本上会发现其原理大致相同.同样是基于 CNI bridge,使用 rancher 提供的 rancher-cni-bridge 、rancher-cni-ipam,网络配置信息以 metadata 方式注入.

区别就在于 rancher-net 容器内部,rancher-net 激活的是 vxlan driver,它会生成一个 vtep1042 设备,并开启 udp 4789 端口,这个设备基于 udp 4789 构建 vxlan overlay 的两端通信,对于本机的容器通过 eth0 走 bridge 通信,对于其他Host的容器,则是通过路由规则转发到 vtep1042 设备上,再通过 overlay 到对端主机,由对端主机的 bridge 转发到相应的容器上.整个过程如图所示：

4、Rancher的扁平网络实现

为什么需要扁平网络,因为容器目前主流的提供的都是 Overlay 网络,这个模式的好处是,灵活、容易部署、可以屏蔽网络对应用部署的阻碍.

但是对很多用户而言,这样也带来了额外的网络开销,网络管理不可以控制,以及无法与现有 SDN 网络进行对接.

在实现扁平网络后,容器可以直接分配业务 IP,这样访问容器上的应用就类似访问 VM 里的应用一样,可以直接通过路由直达,不需要进行 NAT 映射.但扁平网络带来的问题是,会消耗大量的业务段 IP 地址,同时网络广播也会增多.

4.1 扁平网络实现

在 Rancher 环境中实现扁平网络需要使用自定义的 bridge,同时这个 bridge 与 docker0 并没有直接关系.

我们可以给容器添加新的网桥 mybridge,并把容器通过 veth 对连接到网桥上 mybridge 上,如果要实现容器访问宿主机的 VM 上的服务可以将虚拟机配置的IP也配置到网桥上.

进行如上配置后,容器就可以实现 IP 之间路由直接访问.此图中的 vboxnet bridge 可以看做是用户环境的上联交互机.

在VM和物理机的混合场景,所采用的方法也很类型,这边就不再多做解释了.

Rancher CNI 网络环境实现扁平网络的工作流如下：

在实现容器扁平网络的基本配置后,就需要考虑和 Rancher 的集成,Rancher 的 Network-plugin 的启动依赖于 Metadata,而 Metadata 和 DNS server 均使用 docker0 的 bridge 网络(IP为169.254.169.250).

即用户配置的扁平网络要能够访问到 docker0 网络,否则 Rancher 提供的服务发现与注册以及其它为业务层提供的服务将不可用.目前主要方法如下图所示：

1. container-1 内部有到达 169.254.169.250 的一条主机路由,即要访问 169.254.169.250 需要先访问 10.43.0.2；
2. 通过 veth-cni 与 veth-doc 的链接,CNI bridge 下的 container-1 可以将 ARP 请求发送到 docker0 的 10.43.0.2 地址上.由于 10.1.0.2 的 ARP response 报文是被 veth-cni 放行的,于是 container-1 能够收到来自 10.43.0.2 的 ARP response 报文.
3. 然后 container-1 开始发送到 169.254.169.250 的 IP 请求,报文首先被送到 docker0 的 veth-doc 上,docker0 查询路由表,将报文转到 DNS/metadata 对应的容器.然后IP报文原路返回,被 docker0 路由到 veth1 上往 br0 发送,由于来自 169.254.169.250 的 IP 报文都是被放行的,因此 container-1 最终能够收到 IP.
4. 由于属于该 network 的所有的宿主机的 docker0 上都需要绑定 IP 地址 10.43.0.2；因此,该IP地址必须被预留,即,在 catalog 中填写 CNI 的 netconf 配置时,不能将其放入IP地址池.
5. 同时,为了保障该地址对应的 ARP 请求报文不被发送出主机,从而收到其他主机上对应接口的 ARP 响应报文,需要对所有请求 10.1.0.2 地址的 ARP REQUEST 报文做限制,不允许其通过 br0 发送到宿主机网卡.

（编辑：ASP站长网）