十分钟漫谈容器网络方案 01—Flannel

在《Docker和Kubernetes的前世今生（下）》中我们介绍了作为目前主流的容器编排系统，Kubernetes 支持的功能和为容器集群业务带来的便利。而为了设计并保障编排系统运作，Kubernetes 对容器集群进行了这样的要求：任何 pods 之间的通信都可以在不使用 NAT 的情况下进行，即设定集群内所有容器都是连通的。但 Docker 容器通过 Namespace 隔离，无法直接相互通信，默认可以通过共用宿主机的 Network Namespace 的方式，凭借宿主机的网络栈进行通讯。这样的方式也导致了一系列问题，比如征用宿主机端口时使端口资源很快不足使得通信规模受限，以及容器与宿主机共享的网络会暴露宿主机信息，致使网络传输存在安全隐患。

为什么需要 Overlay Network？

为了不影响隔离性并实现容器间的网络通信，Docker 通过虚拟网桥“连接”容器，使容器得以像物理节点一样经过“交换机”通讯。Docker 在宿主机上创建名为 docker0 的虚拟网桥，对于每一个创建的容器均创建一对虚拟网卡设备，其中一端在 docker0，另一端映射到容器内的 eth0，并对容器内网卡分配一个容器网络 IP。通过这一对虚拟网卡，容器就相当于“连接”到网桥上，虚拟网卡接在网桥上时只负责接受数据包，不再调用网络协议栈进行处理，因此只具有类似端口的作用。当容器 A 要访问容器 B 时，只需要广播 ARP 协议，通过 docker0 转发请求到对应”端口”，就实现了数据的转发。

然而，虽然虚拟网桥解决了同一宿主机下的容器间通信问题，以及容器与外部世界之间的通信，但是跨节点的容器通信依然存在问题。集群中每个节点的 docker0 都是独立的，不同节点分配的容器 IP 之间存在冲突的可能，因此需要有一个具有全局视角的上层网络以实现跨节点的容器网络，这便是 Overlay Network 解决方案的由来。

Flannel 容器集群网络方案的出现

Flannel 是由 CoreOS 提出的跨主通信容器网络解决方案，通过分配和管理全局唯一容器 IP 以及实现跨组网络转发的方式，构建基于 Overlay Network 的容器通信网络。作为最早出现的网络编排方案，Flannel 是最简单的集群编排方案之一，为容器跨节点通信提供了多种网络连接方式，后续很多插件的方案也是基于 Flannel 的方案进行扩展。Flannel 的框架包含以下组件：每个节点上的代理服务 flanneld，负责为每个主机分配和管理子网；全局的网络配 f 置存储 etcd（或 K8S API）负责存储主机和容器子网的映射关系；多种网络转发功能的后端实现。本文主要介绍三种最常见的模式：UDP、VXLAN 和 Host-gateway（以下简称 host-gw）。

Flannel 在 Kubernetes 集群中的架构图https://www.cnblogs.com/liuhongru/p/11168269.html

Flannel 数据转发模式之 UDP

UDP 是与 Docker 网桥模式最相似的实现模式。不同的是，UDP 模式在虚拟网桥基础上引入了 TUN 设备（flannel0）。TUN 设备的特殊性在于它可以把数据包转给创建它的用户空间进程，从而实现内核到用户空间的拷贝。在 Flannel 中，flannel0 由 flanneld 进程创建，因此会把容器的数据包转到 flanneld，然后由 flanneld 封包转给宿主机发向外部网络。

UDP 转发的过程为：Node1 的 container-1 发起的 IP 包（目的地址为 Node2 的 container-2）通过容器网关发到 docker0，宿主机根据本地路由表将该包转到 flannel0，接着发给 flanneld。Flanneld 根据目的容器容器子网与宿主机地址的关系（由 etcd 维护）获得目的宿主机地址，然后进行 UDP 封包，转给宿主机网卡通过物理网络传送到目标节点。在 UDP 数据包到达目标节点后，根据对称过程进行解包，将数据传递给目标容器。

UDP 模式工作模式图https://www.cnblogs.com/chenqionghe/p/11718365.html

UDP 模式使用了 Flannel 自定义的一种包头协议，实现三层网络 Overlay 网络处理跨主通信的问题。但是由于数据在内核和用户态经过了多次拷贝：容器是用户态，docker0 和 flannel0 是内核态，flanneld 是用户态，最终又要通过内核将数据发到外部网络，因此性能损耗较大，对于有数据传输有要求的在线业务并不适用。

UDP 模式数据包的传递过程https://blog.csdn.net/CSUXD/article/details/101082697

Flannel 数据转发模式之 VXLAN

如果要进行性能优化，就需要减少用户态与内核态之间的数据拷贝，这就是 VXLAN 模式解决的问题。VXLAN 的核心在于在三层网络的基础上构建了二层网络，使分布在不同节点上的所有容器在这个虚拟二层网络下自由通信。二层虚拟网络通过 VXLAN 在宿主机上创建的 VTEP 设备（flannel.1）实现，flannel.1 和 flanneld 一样负责封包解包工作，不同的是 flannel.1 的封解包对象是二层数据帧，在内核中完成。

VXLAN 的转发过程为：Node1 的容器 container-1 发出的数据包经过 docker0，路由给 VTEP 设备。每个在 flannel 网络中的节点，都会由 flanneld 维护一张路由表，指明发往目标容器网段的包应该经过的 VTEP 设备 IP 地址。Node1 的 VTEP 会获得数据包应该发向 Node2 的 VTEP 设备的 IP，并通过本地的 ARP 表知道目的 VTEP 设备的 MAC 地址，然后封装在数据包头部构成二层数据帧并再加上 VXLAN 头，标识是由 VTEP 设备处理的数据帧。另外，flannel 会维护转发数据库 FDB，记录目标 VTEP 的 MAC 地址应该发往的宿主机（也就是 Node2），宿主机网卡将封装为外部网络传输的包转发到 Node2。数据帧在 Node2 上解封后，宿主机会识别 VXLAN 头部，直接在内核拆包，然后转发到目标 VTEP 设备并转到对应容器。

VXLAN 模式工作模式图https://www.cnblogs.com/chenqionghe/p/11718365.html

作为 Flannel 中最被普遍采用的方案，VXLAN 采用的是内置在 Linux 内核里的标准协议，因此虽然封包结构比 UDP 模式复杂，但装包和解包过程均在内核中完成，实际的传输速度要比 UDP 模式快许多。较快的传输速度和对底层网络的可兼容性也使得 VXLAN 适用性较其他模式更高，成为业务环境下的主流选择。

Flannel 数据转发模式之 Host-gw

除去上述两种模式外，Flannel 还提供了一种纯三层网络模式 host-gw。顾名思义，host-gw 是一种主机网关模式，每个主机会维护一张路由表，记录发往某目标容器子网的数据包的下一跳 IP 地址（也就是子网所在宿主机的 IP）。宿主机将下一跳目的主机的 MAC 地址作为目的地址，通过二层网络把包发往目的主机。目的主机收到后，会直接转发给对应容器。所以 host-gw 模式下，数据包直接以容器 IP 包的形式在网络中传递，每个宿主机就是通信链路中的网关。

Host-Gateway 模式工作模式图https://www.cnblogs.com/chenqionghe/p/11718365.html

和其他两种模式相比，host-gw 模式少了额外的封包和拆包过程，效率与虚拟机直接的通信相差无几。但是，该模式要求所有节点都在物理二层网络中联通，且每个主机都需要维护路由表，节点规模较大时有较大的维护压力，因此不适用复杂网络。

基于星环 TCOS 的 Flannel 性能测试

目前 UDP 模式由于其性能问题已基本被弃用，因此对于三层物理网络首选 VXLAN 模式，而二层网络 VXLAN 和 host-gw 均可选用。为了测试 VXLAN 和 host-gw 在二层网络下性能，我们在实验子网内对两种模式进行了性能对比，以便更好的根据场景选择模式。我们从带宽和转发吞吐量两个方面考察性能，选择了 IPerf 和 netperf 两种网络性能测试工具。

两种模式在不同 TCP window 大小下的传输速率比较

两种模式不同数据负载下的吞吐量比较

根据上面两张测试数据可以得出：1、在 TCP 数据接收窗口相同的情况下，host-gw 平均传输速度更快，比 VXLAN 快约 20%，实验环境下最终趋于相近的速率；2、host-gw 的平均吞吐量较 VXLAN 模式高出约 5%。由此可见，对于小规模集群、二层网络下的通信，可以优先选择 host-gw；而大规模集群、三层网络下的通信更适合走 VXLAN 模式。

和市场上很多云服务商一样，星环 TCOS 云操作系统的容器网络方案也兼容了 Flannel。TCOS 默认使用 VXLAN 模式，以满足复杂网络场景如跨子网通信、异地数据中心互联等，更加适合私有云部署的复杂场景。另外，TCOS 也保留了 host-gw 模式，为小规模企业的扁平化网络提供通信方案，或者网络拓扑较简单的公有云环境下使用。

TCOS 还对 Flannel 进行了二次开发，在自行维护了多网络和网络防火墙功能的同时，引入 Flannel 并不具备的 Network Policy，以对 Pod、Service 和 NameSpace 进行精细化的防火墙管理。在 TCOS 网络方案下，不同租户可以根据需要创建网络，彼此之间互不影响，满足了多租户网络管理隔离。

Flannel 出现后网络编排方案的发展

Flannel 作为最早的跨网络通信解决方案，提供了自动化简单的策略，可以满足一般情况下的跨节点容器通信。市场上的云服务商如 CDK Global、Ranchor、Platform9 等都选择在支持其他方案的基础上保留了 Flannel，足以见其在容器网络通信的适用性。作为容器网络解决方案的先驱者，Flannel 和其他企业级开源解决方案如 Calico、Weave 等一同驱动了网络方案发展。

然而，虽然 Flannel 是最早为 Kubernetes 集群设计的自动化网络方案，但其功能并不完善，如不支持 Kubernetes 的 Network Policy，对于有容器隔离需求的业务有着很大局限性。基于 Flannel 存在的问题和缺陷，也衍生出一批支持 Network Policy、具备负载均衡功能等改良集群网络方案。这些方案从某种意义上来说可以被看做是 Fannel 的改进版，为 Kubernetes 的容器集群网络通信提供了更多的选择，网络编排方案开始进入百花争鸣的时代。

往期原创文章 ：

TCOS – 业界首个支持生产级大数据业务的容器操作系统

TDC–带来新一代大数据产品形态

行业观察: 云+大数据+AI推动企业数据业务演进TCOS 2.0 发布 | 面向异构联邦的容器操作系统Docker与Kubernetes的前世今生（上）Docker和Kubernetes的前世今生（下）DevOps与SRE在容器时代下的发展与变化

作者介绍：

本文转载自大数据开放实验室，已经过对方授权。大数据开放实验室由星环信息科技（上海）有限公司运营，致力于大数据技术的研究和传播。