Kubernetes 网络插件详解 - Flannel 篇

Kubernetes 本身并没有自己实现容器网络，而是借助 CNI 标准，通过插件化的方式来集成各种网络插件，实现集群内部网络相互通信。Kubernetes 集群设计了 Cluster IP、Node IP、Pod IP 三种类型的通信 IP：Cluster IP 是 Service 对象的 IP 地址，实现 Pod 服务的负载均衡，外部网络无法 ping 通，只在集群内部可以访问使用，是一个虚拟的 IP；Node IP 是集群节点 Node 的 IP 地址，可以是物理机的 IP（也可能是虚拟机 IP）；Pod IP 是容器组 Pod 的 IP 地址，是在容器组初始化过程由 Pause 容器申请的 IP 地址。其中 Pod IP 是容器网络接口 CNI 与具体的网络插件来实现 IP 的申请及数据包的转发。

Flannel 是 CoreOS 开源的，Overlay 模式的 CNI 网络插件，Flannel 在每个集群节点上运行一个 flanneld 的代理守护服务，为每个集群节点（HOST）分配一个子网（SUBNET），同时为节点上的容器组（POD）分配 IP，在整个集群节点间构建一个虚拟的网络，实现集群内部跨节点通信。Flannel 的数据包在集群节点间转发是由 backend 实现的，目前，已经支持核心官方推荐的模式有 UDP、VXLAN、HOST-GW，以及扩展试用实验的模式有 IPIP，AWS VPC、GCE、Ali VPC、Tencent VPC 等路由，其中 VXLAN 模式在实际的生产中使用最多。

核心模式 

UDP 模式

UDP 模式简单来说，就是数据报文在发送实际物理网络之前，通过 flanneld 进行一层 UDP 封装，将数据报文作为 payload 发送给对端，对端收到 UDP 报文之后，flanneld 通过解包得到真正的数据报文后，再转发至最终的服务端，如图一所示。

UDP 模式的核心点是虚拟网络设备 tun/tap，该设备一端连接协议栈，另外一端连接用户程序，允许用户程序像读写文件一样进行收发数据包。tun/tap 工作原理基本一致，tun 模拟是三层网络设备，收发的是 IP 层数据包；tap 模拟是二层网络设备，收发以太网数据帧。

在 UDP 模式，Flannel 通过 DaemonSet 控制器，在每个节点启动一个 kube-flannel 的 Pod，同时会创建两个虚拟网络设备，cni0 与 flannel0，如图二所示，其中 cni0 是 linux bridge 设备，而 flannel0 则是 Tun 设备。

在同一个 Kubernetes 集群中，Pod 通信有同节点 Pod 通信及跨节点 Pod 通信两种场景，其中同节点 Pod 通信，由于 cni0 是类二层转发设备，可以直接实现数据包的转发，所以同节点的 Pod 间通信，直接通过 Linux bridge cni0 来实现。跨节点 Pod 通信则是三层虚拟网络设备 Tun，也就是 flannel0。当 Pod 数据包通过路由发送到 flannel0 上，节点主机上的 flanneld 进程就会收到 IP 包，并将 IP 包封装在一个 UDP 包，通过物理网络发送给目的宿主机。同理目的主机就会有 UDP 解包及转发至 Pod 服务。

UDP 模式比较简单，但是由于 flanneld 运行在用户态，而数据的交互和传递则在内核态完成，会经历两次的内核态和用户态数据拷贝，性能损耗巨大，所以 UDP 模式已经逐渐废弃。如图四所示，是一个完成 UDP 模式数据包转发过程及路由表。

VXLAN 模式

VXLAN (Virtual Extensible LAN)是一种网络虚拟化技术，它使用一种隧道协议将二层以太网帧封装在四层 UDP 报文中，通过三层网络传输，组成一个虚拟大二层网络。VXLAN 使用 VTEP（VXLAN Tunnel Endpoint）来进行封包和解包：在发送端，源 VTEP 将原始报文封装成 VXLAN 报文，通过 UDP 发送到对端 VTEP；在接收端，VTEP 将解开 VXLAN 报文，将原始的二层数据帧转发给目的的接收方。VTEP 可以是独立的网络设备，例如交换机，也可以是部署在服务器上的虚拟设备。例如使用置顶交换机（TOR）作为 VTEP 时，VXLAN 的网络模型如下图：

Flannel 默认和推荐的模式就是 VXLAN，当使用默认配置安装 Flannel 时，会为每个节点分配一个 24 位子网，并在每个节点上创建两张虚机网卡 cni0 和 flannel.1：其中 cni0 是一个网桥设备，节点上所有的 Pod 都通过 veth pair 的形式与 cni0 相连；而 flannel.1 则是一个 VXLAN 类型的设备，充当 VTEP 的角色实现对 VXLAN 报文的封包解包。

   同节点 Pod 通信，与 UDP 模式一样，通过 cni0 网桥完成，不涉及 VXLAN 报文的封包解包操作；跨节点 Pod 通信则是通过静态配置路由表，ARP（address resolution protocol 地址解析协议）表和 FDB 表（Forwarding database 二层设备中 MAC 地址和端口的关联关系）的信息，通过 VXLAN 虚拟网卡 flannel.1，实现了集群内所有 Pod 在同一个大二层网络相互通信。还有 VXLAN 模式支持 DirectRouting 配置，DirectRouting=true 是支持在相同子网情况下数据包直接通过路由转发，与 HOST-GW 模式相同。

UDP 模式和 VXLAN 模式都是属于隧道方式，也就是在 UDP 的基础之上，构建虚拟网络，VXLAN 模式只是将 UDP 模式的 flanneld 进程换成了 VTEP 设备，通过 VTEP 设备完成封包和解包的过程；另外一个关键点是 VXLAN 模式全过程全部在内核态完成，flannel.1 充当网桥的角色，进行 UDP 数据包的转发，所以性能要比 UDP 模式好很多。

HOST-GW 模式

与 UDP 模式和 VXLAN 模式不同，HOST-GW 模式属于路由的方式，无需经过任何封包和解包，纯路由机制实现，因此性能比较高。但是 HOST-GW 模式只支持宿主机之间二层连接，要求集群中所以节点必须处于同一个网络中。如果不在一个网络中，三层设备路由器缺少 Pod 网络的路由规则，无法转发数据包。

HOST-GW 模式将目的主机当作网关，直接路由原始的数据包。flanneld 会在集群节点上创建并维护路由表，当数据包到达集群节点的时，就会根据路由表直接发送到下一跳，也就是同网段的节点 IP，直接通过二层网络将数据转发到目的节点上；目的节点再根据路由表规则转发到 cni 网桥，网桥根据路由规则转发到容器里面。

HOST-GW 模式通过路由转发实现高性能网络通信，但是这种模式局限性很大，节点之间都要相互有点对点的路由覆盖，每个节点上有 n-1 个路由，而 n 个节点共有 n(n-1)/2 个路由，才能保证 flannel 的 flat 网络能力。

扩展模式

IPIP 模式

IPIP 模式是一种简单隧道方式，通过内核 IPIP 封装数据包，开销低但只能封装 ipv4 单播通信，因此无法设置 OSPF、RIP 或任何其他基于多播的协议。

在 IPIP 模式，会有两个 IPIP 隧道设备 tunl0 和 flannel.ipip，其中 tunl0 由 ipip 的内核模块，在 modprobe ipip 模块的网络命名空间（network namespace）自动创建，是命名空间默认 IPIP 设备，包含 local=any 和 remote=any 属性，flannel.ipip 是由 flannel 创建的一对多 ipip 设备。当接收到 IPIP 协议数据包时，内核在 local/remote 属性中存在精确匹配 src/dst 的 IP 地址，就会解包转到内部服务，否则会将数据包转发到 tunl0 备用设备。同样，还有 IPIP 模式也支持 DirectRouting 配置，DirectRouting=true 是支持在相同子网情况下数据包直接通过路由转发，与 HOST-GW 模式相同。

CloudVPC

Kubernetes 容器很多情况下都是部署在公有云之上，容器集群的网络需要云其他产品互联互通，Flannel 支持公有云 Cloud VPC 模式，在 AWS VPC，AliVPC，TencentCloud VPC 运行容器集群，就可以直接使用 VPC 的路由表，将容器内部 IP 实时同步到路由表中，这样容器内部 IP 与其他云产品相互通信，比如 ELB 就可以直接配置路由到容器内部，不过有的公有云要路由条数有限制，或者需要额外收费。

总结

总的来说，Kubernetes 网络比较复杂，主要是涉及到容器运行时 CRI，容器网络标准 CNI，以及容器网络插件三个方面配合及协调，同时在灵活易用及性能优化上持续演进。Flannel 作为使用最广网络插件，主要具备两大优势：首先从 UDP，VXLAN，HOST-GW 到 IPIP，不仅是场景覆盖与性能的权衡演进，还有对底层操作核心能力的快速支持，社区一直保持活跃。其次开放与云平台的集成，容器大部分运行环境都是在云平台之上，与云平台的集成直接使用底层云能力实现网络能力，提供开箱即用且高效网络方案，将云的能力最大化，始终贯彻云原生的理念。

关注“巨子嘉”，巨子出品，必属精品