一、背景简介
K8S网络方案旨在解决容器间的跨主机通信，目前Kubernetes支持的网络方案有：Flannel、Calico、Canal、Cilium、Kube-router、Romana、WeaveNet、JuniperContrail/TungstenFabric。目前常用的有Flannel和Calico。今天会介绍一下Flannel的网络模式。
1.Flannel简介
flannel是 CoreOS 团队针对 Kubernetes设计的一个覆盖网络(overlay network)管理工具，其目的在于帮助每一个使用 Kuberentes 的 CoreOS 主机拥有一个完整的子网，实现容器间的网络通信。支持3种网络模式：UDP、VXLAN、HOST-GW
2.Underlay和Overlay简介
Underlay：指的是物理网络，它由物理设备和物理链路组成。常见的物理设备有交换机、路由器、防火墙、负载均衡、入侵检测、行为管理等，这些设备通过特定的链路连接起来形成了一个传统的物理网络，这样的物理网络，我们称之为Underlay网络。
Overlay：指的是在现有的物理网络之上构建的虚拟网络。是一种网络架构上叠加的虚拟化技术。本质是一种隧道技术，将原生态的二层数据帧（MAC）报文进行封装后在通过隧道进行传输。通过Overlay技术，我们在对物理网络不做任何改造的情况下，通过隧道技术在现有的物理网络上创建了一个或多个逻辑网络即虚拟网络。VXLAN，NVGRE及STT是典型的三种隧道技术。
二、Flannel网络介绍
1.VXLAN模式
VXLAN原理
原本各个主机之间的容器是相互隔离的。VXLAN模式的思想就是在各个主机之间建立一个虚拟的通道，即VXLAN隧道。
VXLAN(Virtual Extensible LAN)，是一种网络虚似化技术，基于 IP 网络且采用“MAC in UDP”封装形式的二层 VPN 技术。是对VLAN技术的一种扩展。
这里重点解释一下什么叫MAC in UDP：
VXLAN是通过UDP进行传输的：即图中OuterUDPheader部分即之前都是普通的UDP报文头，这里对应源容器主机到目标容器主机的IP和端口号。UDP报文头之后是UDP的数据区域。从图中可以看出，UDP数据区存储了VXLAN header和原始报文部分。
VXLAN header：存放了VXLAN协议定义的数据：VXLAN Flages（VXLAN标识符）和VNI（网络标识符），其余为保留位。
原始报文部分：源容器到目标容器的IP和端口号，以及携带的数据信息。
VXLAN模式示意图：
图示背景：
宿主机A IP：192.168.0.100，PodFrontend：10.1.15.2
宿主机B IP：192.168.0.200，PodBackend： 10.1.20.3
PodFrontend 需要跨主机访问 Pod Backend
VXLAN流量流向
1.Frontend发出请求，源地址：Pod Frontend的IP，目标地址：Pod Backend的IP
2.流量通过容器的网卡进入veth0，然后进入cni0网桥，cni0网桥类似于交换机，发现目标地址不在同一子网内，于是发给flannel.1。（K8S中统一使用cni0网桥代取docker0网桥）
3.flannel.1将请求发送到linux内核，linux内核负责对请求包装，加上外层UDP报头，源地址：Pod Frontend主机的IP，目标地址：Pod Backend主机的IP。内核将请求发到Pod Backend主机。
4.Pod Backend主机收到请求后，内核发现是vxlan报文，去除外层的UDP报头，得到真实的请求，源地址：Pod Frontend的IP，目标地址：Pod Backend的IP。
5.请求会从flannel.1经过docker0网桥，发给Pod Backend，Pod Backend收到Pod Frontend的请求。
总结
1.Flannel的本质VXLAN本质是使用了内核的vxlan模块进行跨主机通信。
2.因此VXLAN模式对内核版本有要求，需要内核的版本至少3.7+, 推荐为3.9+
3.通信的过程中需要进行封包、解包操作，因此对性能有一定的损耗，属于3种模式中性能较好的方案，对主机网络没有限制，是一种灵活的组网方式。
2.UDP模式
Flannel UDP模式，原理与VXLAN模式类似，都是Packagein UDP。区别在于VXLAN模块是Linux的内核模块，因此vxlan模式是在内核做的报文封装。而UDP模式下，需要利用Flanneld在用户态进行封包解包。再将处理好的包交给linux内核发出。
特点
1.由于UDP模式下用户态和内核态的切换更为频繁，同时状态的切换是需要带来性能损耗的。因此相比于VXLAN模式，UDP模式的性能不会太好，属于3种中最差的。
2.优点是兼容性好，对内核版本没有要求
3.但是官方原话是说UDP模式仅用于Debug，而且性能不够好，因此不建议生产环境使用。
3.HOST-GW模式
HOST-GW模式全称为（host-gateway），顾名思义该模式的思路是把每个主机都配置成一个网关（可以理解为路由器）。每个主机按照路由规则，可以将流量转发到其他子网对应的主机上。具体对应关系可以使用：ip route命令查看，如图所示
HOST-GW模式示意图：
图示背景：
宿主机A IP：192.168.0.100，PodFrontend：172.17.0.2
宿主机B IP：192.168.0.200，PodBackend：172.17.1.2
AppFrontend 需要跨主机访问 App Backend
HOST-GW流量流向
1.Frontend发出请求，源地址：App Frontend的IP，目标地址：App Backend的IP
2.流量通过容器的网卡进入veth0，然后进入cni0网桥，cni0网桥类似于交换机，发现目标地址不在同一子网内，于是发给宿主机网卡eth0。（K8S中统一使用cni0网桥代取docker0网桥）。HOST-GW模式没有封包解包的过程，因此没VXLAN中的flannel设备。
3.宿主机网卡收到请求后，查询目标IP，发现不是同一子网，因此会去查找路由表，根据路由表（ip route命令的列表），将请求发送到App Backend所在宿主机。
4.Pod Backend宿主机收到请求后，通过iptables路由表，将请求发给本机的cni0设备，cni0设备将请求发给容器AppBackend的veth pair。到达容器AppBackend
特点
1.HOST-GW模式每台主机都需要作为网关，实现容器跨主机通信。因此所有主机间必须二层可达（即在同一子网）。对宿主机的网络环境有一定的要求，因此需要前期规划好设备数量，划分子网。且后期添加节点时也对机器的IP有要求，需要在同一子网。
2.不需要额外的封包解包，性能最好
3.对linux的内核版本没有要求兼容性好
以上就是对Flannel网络模式的总结，如有问题欢迎批评指正。
