Flannel 是一个非常简单的 overlay 网络（VXLAN），是 Kubernetes 网络 CNI 的解决方案之一。Flannel 在每台主机上运行一个简单的轻量级 agent flanneld 来监听集群中节点的变更，并对地址空间进行预配置。Flannel 还会在每台主机上安装 vtep flannel.1（VXLAN tunnel endpoints），与其他主机通过 VXLAN 隧道相连。

　　flanneld 监听在 8472 端口，通过 UDP 与其他节点的 vtep 进行数据传输。到达 vtep 的二层包会被原封不动地通过 UDP 的方式发送到对端的 vtep，然后拆出二层包进行处理。简单说就是用四层的 UDP 传输二层的数据帧。

　　在 Kubernetes 发行版 K3S[1] 中将 Flannel 作为默认的 CNI 实现。K3S 集成了 flannel，在启动后 flannel 以 go routine 的方式运行。

　　环境搭建

　　Kubernetes 集群使用 k3s 发行版，但在安装集群的时候，禁用 k3s 集成的 flannel，使用独立安装的 flannel 进行验证。

　　安装 CNI 的 plugin，需要在所有的 node 节点上执行下面的命令，下载 CNI 的官方 bin。

　　安装 k3s 的控制平面。

　　安装 Flannel。这里注意，Flannel 默认的 Pod CIRD 是 10.244.0.0/16，我们将其修改为 k3s 默认的 10.42.0.0/16。

　　添加另一个节点到集群。

　　查看节点状态。

　　运行两个 pod：curl 和 httpbin，为了探寻

　　网络配置

　　接下来，一起看下 CNI 插件如何配置 pod 网络。

　　初始化

　　Flannel 是通过 Daemonset 的方式部署的，每台节点上都会运行一个 flannel 的 pod。通过挂载本地磁盘的方式，在 Pod 启动时会通过初始化容器将二进制文件和 CNI 的配置复制到本地磁盘中，分别位于 /opt/cni/bin/flannel 和 /etc/cni/net.d/10-flannel.conflist。

　　通过查看 kube-flannel.yml[2] 中的 ConfigMap，可以找到 CNI 配置，flannel 默认委托（见 flannel-cni 源码 `flannel_linux.go#L78`[3]）给 bridge 插件[4] 进行网络配置，网络名称为 cbr0；IP 地址的管理，默认委托（见 flannel-cni 源码 `flannel_linux.go#L40`[5]） host-local 插件[6] 完成。

　　还有 Flannel 的网络配置，配置中有我们设置的 Pod CIDR 10.42.0.0/16 以及后端（backend）的类型 vxlan。这也是 flannel 默认的类型，此外还有 多种后端类型[7] 可选，如 host-gw、wireguard、udp、Alloc、IPIP、IPSec。

　　Flannel Pod 运行启动 flanneld 进程，指定了参数 --ip-masq 和 --kube-subnet-mgr，后者开启了 kube subnet manager 模式。

　　运行

　　集群初始化时使用了默认的 Pod CIDR 10.42.0.0/16，当有节点加入集群，集群会从该网段上为节点分配 属于节点的 Pod CIDR 10.42.X.1/24。

　　flannel 在 kube subnet manager 模式下，连接到 apiserver 监听节点更新的事件，从节点信息中获取节点的 Pod CIDR。

　　然后在主机上写子网配置文件，下面展示的是其中一个节点的子网配置文件的内容。另一个节点的内容差异在 FLANNEL_SUBNET=10.42.1.1/24，使用的是对应节点的 Pod CIDR。

　　CNI 插件执行

　　CNI 插件的执行是由容器运行时触发的，具体细节可以看上一篇 《源码解析：从 kubelet、容器运行时看 CNI 的使用》。

　　Flannel Plugin Flow

　　flannel 插件

　　flannel CNI 插件（/opt/cni/bin/flannel）执行的时候，接收传入的 cni-conf.json，读取上面初始化好的 subnet.env 的配置，输出结果，委托给 bridge 进行下一步。

      bridge 插件

　　bridge 使用上面的输出连同参数一起作为输入，根据配置完成如下操作：

　　创建网桥cni0（节点的根网络命名空间）

　　创建容器网络接口eth0（ pod 网络命名空间）

　　创建主机上的虚拟网络接口vethX（节点的根网络命名空间）

　　将vethX 连接到网桥 cni0

　　委托 ipam 插件分配 IP 地址、DNS、路由

　　将 IP 地址绑定到 pod 网络命名空间的接口eth0 上

　　检查网桥状态

　　设置路由

　　设置 DNS

　　最后输出如下的结果：

　　port-mapping 插件

　　该插件会将来自主机上一个或多个端口的流量转发到容器。

　　Debug

　　让我们在第一个节点上，使用 tcpdump 对接口 cni0 进行抓包。

     从 pod curl 中使用 pod httpbin 的 IP 地址 10.42.1.2 发送请求：

　　cni0

　　从在 cni0 上的抓包结果来看，第三层的 IP 地址均为 Pod 的 IP 地址，看起来就像是两个 pod 都在同一个网段。

　　tcpdump-on-cni0

　　host eth0

　　文章开头提到 flanneld 监听 udp 8472 端口。

　　我们直接在以太网接口上抓取 UDP 的包：

　　再次发送请求，可以看到抓取到 UDP 数据包，传输的负载是二层的封包。

　　tcpdump-on-host-eth0

　　Overlay 网络下的跨节点通信

　　在系列的第一篇中，我们研究 pod 间的通信时提到不同 CNI 插件的处理方式不同，这次我们探索了 flannel 插件的工作原理。希望通过下面的图可以对 overlay 网络处理跨节点的网络通信有个比较直观的认识。

　　当发送到 10.42.1.2 流量到达节点 A 的网桥 cni0，由于目标 IP 并不属于当前阶段的网段。根据系统的路由规则，进入到接口 flannel.1，也就是 VXLAN 的 vtep。这里的路由规则也由 flanneld 来维护，当节点上线或者下线时，都会更新路由规则。

　　flannel.1 将原始的以太封包使用 UDP 协议重新封装，将其发送到目标地址 10.42.1.0 （目标的 MAC 地址通过 ARP 获取）。对端的 vtep 也就是 flannel.1 的 UDP 端口 8472 收到消息，解帧出以太封包，然后对以太封包进行路由处理，发送到接口 cni0，最终到达目标 pod 中。

　　响应的数据传输与请求的处理也是类似，只是源地址和目的地址调换。

　　参考资料

　　[1] K3S: https://k3s.io/

　　[2] kube-flannel.yml: https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml

　　[3] flannel-cni 源码 flannel_linux.go#L78: https://github.com/flannel-io/cni-plugin/blob/v1.1.0/flannel_linux.go#L78

　　[4] bridge 插件: https://www.cni.dev/plugins/current/main/bridge/

　　[5] flannel-cni 源码 flannel_linux.go#L40: https://github.com/flannel-io/cni-plugin/blob/v1.1.0/flannel_linux.go#L40

　　[6] host-local 插件: https://www.cni.dev/plugins/current/ipam/host-local/

　　[7] 多种后端类型: https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md