【容器网络】跨主通信网络实现方法之host-gw实现原理

以上是VXLAN在跨主通信的实现原理，本文讲述的是host-gw的实现原理。

目录

Host-gw

基本原理

flannel的host-gw

数据包传输过程

calico的host-gw

calico架构

BGP Peer

Node-to-NodeMesh

Route Reflector

IPIP

---

Host-gw

在容器生态中,提供 Host-gw解决方案的有flannel和calico。

基本原理

Host-gw的基本原理如下：

安装网络插件后，网络插件会在每台宿主机上，添加一个格式如下所示的路由规则：

< 目的容器 IP 地址段 > via < 网关的 IP 地址 > dev eth0

其中，网关的 IP 地址，正是目的容器所在宿主机的 IP 地址。即数据包的下一跳地址就是目标容器宿主机所在地址，目标容器宿主机充当了网关，这也就是host-gw名字的由来。

一旦配置了下一跳地址，那么接下来，当 IP 包从网络层进入链路层封装成帧的时候，eth0设备就会使用下一跳地址对应的 MAC 地址，作为该数据帧的目的 MAC 地址。

flannel的host-gw

在flannel中，Flannel 子网和主机的信息，都是保存在 Etcd 当中的。flanneld 只需要 WACTH 这些数据的变化，然后实时更新路由表即可。即维护路由信息是由flanneld进程维护的。

通过以下命令即可查看子网与宿主机对应关系

$ etcdctl ls /coreos.com/network/subnets

这里边记录了子网与宿主机对应关系，比如以下图中的10.244.1.0/24属于192.168.0.3/24这个主机。

在Host-gw模式下，容器通信的过程就免除了额外的封包和解包带来的性能损耗。当 IP 包从网络层进入链路层封装成帧的时候，eth0设备就会使用下一跳地址对应的 MAC 地址，作为该数据帧的目的 MAC 地址。根据实际的测试，host-gw 的性能损失大约在 10% 左右，而其他所有基于 VXLAN“隧道”机制的网络方案，性能损失都在 20%~30% 左右。

但是通过上述分析也可以看到host-gw需要宿主机在二层是连通的。

数据包传输过程

整个数据包从Node X传输到Node Y上的过程如下图所示：

当Node X 上的pod1想要访问Node Y上的pod2时，flanneld会在Node X添加如下规则：

10.244.1.0/24 via 192.168.0.3 dev eth0

表示数据包的下一跳是Node Y的网关，那么接下来，当 IP 包从网络层进入链路层封装成帧的时候，eth0设备就会使用下一跳地址对应的 MAC 地址，作为该数据帧的目的 MAC 地址。显然，这个MAC 地址，正是 Node Y 的 MAC 地址。这样数据包就被发送到了Node Y 的eth0上，eth0收到数据包后，其内核网络栈从二层数据帧里拿到 IP 包后，会“看到”这个 IP 包的目的 IP 地址是 10.244.1.2，即 container1的 IP 地址。这时候，根据 Node Y上的路由表，该数据包进入cni0 网桥，最后进入到 container1 当中。

calico的host-gw

不同于flannel模式，calico会为每一个Pod 创建一对veth设备，其中一端作为Pod 的网络接口，另一端（名称以cali为前缀，后面接随机数字串）留置在节点的根网络名称空间。

其次，不同于 Flannel 通过 Etcd 和宿主机上的 flanneld 来维护路由信息的做法，Calico项目使用BGP来自动地在整个集群中分发路由信息。

linux内核原生支持BGP协议，因此一个主机可以轻易的配置成边界网关。边界网关之间通过 TCP 传输路由信息给其他的边界网关。而其他边界网关上会对收到的这些数据进行分析，然后将需要的信息添加到自己的路由表里。所以说BGP实现了大规模网络中节点路由信息共享。

BGP 的这个能力，正好可以取代 Flannel 维护主机上路由表的功能。而且，BGP 这种原生就是为大规模网络环境而实现的协议，其可靠性和可扩展性，远非 Flannel 自己的方案可比。

calico架构

下面再来看Calico 项目的架构就非常容易理解了。它由三个部分组成：

1. Calico 的 CNI 插件。这是 Calico 与 Kubernetes 对接的部分。

2. Felix。它是一个 DaemonSet，负责在宿主机上插入路由规则（即：写入 Linux 内核的FIB 转发信息库），以及维护 Calico 所需的网络设备等工作，最核心的“下一跳”路由规则，就是由 Calico 的 Felix 进程负责维护的。

3. BIRD。它就是 BGP Client ，专门负责在集群里使用 BGP 协议传输分发路由规则信息。

除了对路由信息的维护方式之外，Calico 项目与 Flannel 的 host-gw 模式的另一个不同之处，就是它不会在宿主机上创建任何网桥设备。

BGP Peer

Calico 项目实际上将集群里的所有节点，都当作是边界路由器来处理，它们一起组成了一个全连通的网络，互相之间通过 BGP 协议交换路由规则。这些节点，我们称为BGP Peer。

Node-to-NodeMesh

Calico 维护的网络在默认配置下，是一个被称为“Node-to-Node Mesh”的模式。这时候，每台宿主机上的 BGP Client 都需要跟其他所有节点的 BGPClient 进行通信以便交换路由信息。但是，随着节点数量 N 的增加，这些连接的数量就会以 N²的规模快速增长，从而给集群本身的网络带来巨大的压力。所以，Node-to-Node Mesh 模式一般推荐用在少于 100 个节点的集群里。而在更大规模的集群中，你需要用到的是一个叫作 Route Reflector 的模式。

Route Reflector

在Route Reflector模式下，Calico 会指定一个或者几个代表的节点，来负责跟所有节点建立 BGP 连接从而学习到全局的路由规则。而其他节点，只需要跟这几个专门的节点交换路由信息，就可以获得整个集群的路由规则信息了。这些专门的节点，就是所谓的 Route Reflector 节点，它们实际上扮演了“中间代理”的角色，从而把 BGP 连接的规模控制在 N 的数量级上。

IPIP

在calico的host-gw模式中，如果跨主通信的两台主机二层网络不连通，需要通过三层路由器转发将两个宿主机网络连通才可以，并且此时需要打开其IPIP模式。

在 Calico 的 IPIP 模式下，Felix 进程在 Node X上添加的路由规则，会稍微不同，如下所示：

10.244.1.0/24 via 192.168.2.2 dev tunl0

可以看到，尽管这条规则的下一跳地址仍然是 Node Y 的 IP 地址，但这一次，要负责将 IP包发出去的设备，变成了 tunl0。注意，是 T-U-N-L-0，而不是 Flannel UDP 模式使用的T-U-N-0（tun0），这两种设备的功能是完全不一样的。

Calico 使用的这个 tunl0 设备，是一个 IP 隧道（IP tunnel）设备。

IP 包进入 IP 隧道设备之后，就会被 Linux 内核的 IPIP 驱动接管。IPIP驱动会将这个 IP 包直接封装在一个宿主机网络的 IP 包中。

得到的数据包结构如下图

由于宿主机之间已经使用路由器配置了三层转发，也就是设置了宿主机之间的“下一跳”。所以这个 IP 包在离开 Node X之后，就可以经过路由器，最终“跳”到 Node Y 上。这时，Node Y 的网络内核栈会使用 IPIP 驱动进行解包，从而拿到原始的 IP 包。然后，原始 IP 包就会经过路由规则和 Veth Pair 设备到达目的容器内部。

整个过程的数据包传送如下图中绿色线条所示:

可以看到，calico的IPIP模式，会存在一些封包解包问题，实际效率上来说和flannel VXLAN模式差不多。所以，在实际使用时，应尽量避免将多个主机放在不同子网，避免使用IPIP模式。