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

以上是容器跨主通信网络实现方法之UDP的实现原理，本文讲述的是VXLAN在跨主通信的实现原理。

VXLAN

VXLAN规范最初是由Cisco，VMware和Arista Networks创建的，全称 Virtual eXtensible Local Area Network。简单的说VXLAN就是扩充了的 VLAN，其包头有一个24bit的ID段，即意味着1600万个独一无二的虚拟网段从而解决当前大型云计算数据中心虚拟网络不足的问题。VXLAN通过封装、转发2层报文，可以使得多个网络的一台一台物理交换机通过三层直接连接，处于网络中的同一个VLAN。

VXLAN，是 Linux 内核本身就支持的一种网络虚似化技术。所以说，VXLAN 可以完全在内核态实现上述封装和解封装的工作，而UDP是在用户态完成封包解包操作的。

VXLAN 的覆盖网络的设计思想是：

在现有的三层网络之上，“覆盖”一层虚拟的、由内核VXLAN 模块负责维护的二层网络，使得连接在这个 VXLAN 二层网络上的“主机”（虚拟机或者容器都可以）之间，可以像在同一个局域网（LAN）里那样自由通信。

VTEP

但实际上，这些“主机”可能分布在不同的宿主机上，甚至是分布在不同的物理机房里。而为了能够在二层网络上打通“隧道”，VXLAN 会在宿主机上设置一个特殊的网络设备作为“隧道”的两端。这个设备就叫作 VTEP，即：VXLAN Tunnel End Point（虚拟隧道端点）。

VTEP 设备的作用，其实跟前面的 提到的跨主通信之UDP实现方法一文中flanneld 进程非常相似。只不过，它进行封装和解封装的对象，是二层数据帧（Ethernet frame）；而且这个工作的执行流程，全部是在内核里完成的（因为 VXLAN 本身就是 Linux 内核中的一个模块）。

数据包传输过程

与前面 UDP 模式的流程类似，当 主机X的container1 发出请求之后，会先出现在 docker0 网桥，然后被路由到本机 flannel.1 设备进行处理。也就是说，来到了“隧道”的入口。为了能够将“原始 IP 包”封装并且发送到正确的宿主机，VXLAN 就需要找到这条“隧道”的出口，即：目的宿主机的 VTEP 设备。

Flannel并非依赖ARP进行MAC地址学习，而是由节点上的flanneld进程在启动时，将本地VETP设备接口IP与MAC地址映射信息上报到Etcd中，并由其他同属于VNI=1的节点上的flanneld动态生成对应的解析记录，这些路由信息可以通过在节点上执行route -n命令进行查看。

得到这个“目的 VTEP 设备”的 MAC 地址，Linux 内核就可以开始二层封包工作了。Linux 内核会把“目的 VTEP 设备”的 MAC 地址，填写在数据包中的 Inner EthernetHeader 字段，得到一个二层数据帧。如下图所示：

但是，上面提到的这些 VTEP 设备的 MAC 地址，对于宿主机网络来说并没有什么实际意义。因为我们要在三层网络中进行传输，数据包的发送方容器和接收方容器在宿主机网段内的子网里，所以我们要先到达目标容器所在的主机，才可以将数据包传输给目标容器。好比是你需要给三年级二班级里的小Q送东西，你得先知道三年级二班在哪里。

所以接下来，Linux 内核还需要再把“内部数据帧”进一步封装成为宿主机网络里的一个普通的数据帧，好让它“载着”“内部数据帧”，通过宿主机的 eth0 网卡进行宿主机网络内的传输。

Linux 内核会在“内部数据帧”前面，加上一个特殊的VXLAN 头，用来表示这个“乘客”实际上是一个 VXLAN 要使用的数据帧。而这个 VXLAN 头里有一个重要的标志叫作VNI，它是 VTEP 设备识别某个数据帧是不是应该归自己处理的重要标识。而在 Flannel 中，VNI 的默认值是 1，这也是为何，宿主机上的VTEP 设备都叫作 flannel.1 的原因，这里的“1”，其实就是 VNI 的值。然后，Linux 内核会把这个数据帧封装进一个 UDP 包里发出去。

那如何知道目标主机的IP地址呢？FDB

flannel.1 设备（VTEP）实际上还要扮演一个“网桥”的角色，在二层网络进行 UDP 包的转发。而在 Linux 内核里面，“网桥”设备进行转发的依据，来自于一个叫作FDB（Forwarding Database）的转发数据库。该数据库指明了到达目标节点的VTEP设备需要经由的下一跳IP，该IP就是目标容器所在节点的IP地址。

而FDB 信息，也是 flanneld 进程负责维护的。它的内容可以通过

bridge fdb show flannel.1 

这个命令查看到。

至于目标主机Y的MAC地址，则是X主机ARP表要学习的内容，与flannel无关。

所以我们得到目标主机IP和MAC信息之后，就可以进行外层VXLAN数据包封装了，得到的数据包如下：

接下来，Node X 上的 flannel.1 设备就可以把这个数据帧从 Node X 的 eth0 网卡发出去。显然，这个帧会经过宿主机网络来到 Node Y 的 eth0 网卡。这时候，Node Y 的内核网络栈会发现这个数据帧里有 VXLAN Header，并且 VNI=1。

所以Linux 内核会对它进行拆包，拿到里面的内部数据帧，然后根据 VNI 的值，把它交给 Node Y上的 flannel.1 设备。而 flannel.1 设备则会进一步拆包，取出“原始 IP 包”。

接下来就数据包传输过程就和单机容器网络的处理流程一样。最终，IP 包就进入到了 目标容器的 NetworkNamespace 里。

总结一下，跨主机容器通信整个过程如下图绿色线条所示，需要注意的是VXLAN和UDP对应的flanneld监控的端口是不一样的。

隧道机制

Flannel UDP 和 VXLAN 模式的工作原理。这两种模式其实都可以称作“隧道”机制。并且有一个共性：

用户的容器都连接在 docker0 网桥上。而网络插件则在宿主机上创建了一个特殊的设备（UDP 模式创建的是 TUN 设备，VXLAN 模式创建的则是 VTEP 设备），docker0 与这个设备之间，通过 IP 转发（路由表）进行协作。然后，网络插件真正要做的事情，则是通过某种方法，把不同宿主机上的特殊设备连通，从而达到容器跨主机通信的目的。

下面给出比较详细的VXLAN协议数据包内容如图所示：

可以看到经过外层封装后的报文就是一个常规的UDP报文，因此，VXLAN overlay网络具有以下优缺点：

1. VXLAN overlay网络可以正常运行在任何能够传输常规UDP报文的环境中，包括一些底层限制的公有云环境。
2. VXLAN overlay不要求各节点同处于一个二层网络，这有利于在更复杂的环境下组建集群。
3. 牺牲了网络报文的小部分载荷能力，降低了性能。

具体原因如下：

依赖于flanneld进程维护的、各VTEP设备形成的二层网络中各设备的ARP解析记录，以及VTEP设备上的FDB转发数据库，使得即使各个节点不在同一IP网络，只要节点间能够路由可达，均可以实现节点间的路由通信，比如，节点一部署在新疆，节点二部署在东北，这样两个节点只要能够通信，那么这两个节点上的容器也就可以通信。因此，VXLAN overlay不要求各节点同处于一个二层网络，这有利于在更复杂的环境下组建集群。

由于网络传输标准MTU大小最大是1500字节，Outer Ethernet Header 部分所占字节数可能为14或者18，14 的情况为 access 口，省去了 4 字节的 VLAN Tag，因此整个VXLAN封装部分所占字节为50 或 54 字节。为了防止频繁分包，要调整 MTU 为 1550 或 1554，这样除去外层VXLAN封装部分所占字节，内层数据帧大小不得超过1450字节。

需要注意的是，对于K8S网络来说，图中维护的网桥设备是cni网桥而不是docker0。

CNI 网桥只是接管所有 CNI 插件负责的、即 Kubernetes 创建的容器（Pod）。而此时，如果你用 docker run 单独启动一个容器，那么 Docker 项目还是会把这个容器连接到 docker0 网桥上。所以这个容器的 IP 地址，一定是属于 docker0 网桥的172.17.0.0/16 网段。

Kubernetes 为 Flannel 分配的子网范围是 10.244.0.0/16。这个参数可以在部署的时候通过 --pod-network-cidr=10.244.0.0/16指定，也可以在部署完成后，通过修改 kube-controller-manager 的配置文件来指定。