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

Rancher 的默认网络目前完成了代码重构,完全支持 CNI 标准,同时也会支持其他第三方 CNI 插件,结合Rancher独有的 Environment Template 功能,用户可以在一个大集群中的每个隔离环境内,创建不同的网络模式,以满足各种业务场景需求,这种管理的灵活性是其他平台没有的.

至于 Rancher 为什么会选择 CNI 标准,最开始 Rancher 也是基于 CNM 进行了开发,但随着开发的深入,我们不得不转向了 CNI,个中原因在本次交流中我们就不做详细说(tu)明(cao)了,

大家如果有兴趣可以参阅：http://blog.kubernetes.io/2016/01/why-Kubernetes-doesnt-use-libnetwork.html

在之前的 Rancher 版本上,用户时常抱怨 Rancher 的网络只有 IPsec,没有其他选择.而容器社区的发展是十分迅猛的,各种容器网络插件风起云涌.

在 Rancher v1.2 之后 Rancher ?全面支持了 CNI 标准,除在容器网络中实现 IPsec 之外又实现了呼声比较高的 VXLAN 网络,同时增加了 CNI 插件管理机制,让用户可以 hacking 接入其他第三方 CNI 插件.随后将和大家一起解读一下 Rancher 网络的实现.

3.1 Rancher-net CNI的IPsec实现

以最简单最快速方式部署 Rancher 并添加 Host,以默认的 IPsec 网络部署一个简单的应用后,进入应用容器内部看一看网络情况,对比一下之前的 Rancher 版本：

最直观的感受便是,网卡名从 eth0 到 eth0@if8 有了变化,原先网卡多 IP 的实现也去掉了,变成了单纯的 IPsec 网络 IP.

这其实就引来了我们要探讨的内容,虽然网络实现还是 IPsec,但是 rancher-net 组件实际上是已经基于 CNI 标准了.最直接的证明就是看一下,rancher-net 镜像的 Dockerfile：

熟悉 CNI 规范的伙伴都知道 /opt/cni/bin 目录是CNI的插件目录,bridge 和 loopback 也是 CNI 的默认插件,这里的 rancher-bridge 实际上和 CNI 原生的 bridge 没有太大差别,只是在幂等性健壮性上做了增强.

而在 IPAM 也就是 IP 地址管理上,Rancher 实现了一个自己的 rancher-cni-ipam,它的实现非常简单,就是通过访问 rancher-metadata 来获取系统给容器分配的 IP.

Rancher 实际上Fork了CNI的代码并做了这些修改,https://github.com/rancher/cni.?这样看来实际上,rancher-net?的 IPsec 和 Vxlan 网络其实就是基于 CNI 的 bridge 基础上实现的.

在解释 rancher-net 怎么和 CNI 融合之前,我们需要了解一下 CNI bridge 模式是怎么工作的.

举个例子,假设有两个容器 nginx 和 mysql,每个容器都有自己的 eth0,由于每个容器都是在各自的 namespace 里面.

所以互相之间是无法通信的,这就需要在外部构建一个 bridge 来做二层转发,容器内的 eth0 和外部连接在容器上的虚拟网卡构建成对的veth设备,这样容器之间就可以通信了.

其实无论是 docker 的 bridge 还是 cni 的 bridge,这部分工作原理是差不多的,如图所示：

那么我们都知道 CNI 网络在创建时需要有一个配置,这个配置用来定义CNI网络模式,读取哪个 CNI 插件.

在这个场景下也就是 cni bridge 的信息,这个信息 rancher 是通过 rancher-compose 传入 metadata 来控制的.

查看 ipsec 服务的 rancher-compose.yml 可以看到,type 使用 rancher-bridge,ipam 使用 rancher-cni-ipam,bridge 网桥则复用了 docker0,有了这个配置我们甚至可以随意定义 ipsec 网络的 CIDR,如下图所示：

ipsec 服务实际上有两个容器：一个是 ipsec 主容器,内部包含rancher-net服务和ipsec需要的charon服务；

另一个 sidekick 容器是 cni-driver,它来控制 cni bridge 的构建.

（编辑：ASP站长网）