1 flannel架构

　　flannel的udp模式和vxlan模式都是属于隧道方式，也就是在udp的基础之上，构建虚拟网络，然后通过一个封包解包的过程来实现数据的传输。

2 flannel的几种模式

　　通过在每一个节点上启动一个叫flannel的进程，负责为每一个节点上的子网划分，并将相关配置信息（如各节点的子网网段、外部IP等）保存到etcd中，而具体的网络报文转发交给backend实现。

　　flanneld可以在启动时通过配置文件指定不同的backend进行网络通信，目前比较成熟的backend有UDP、VXLAN和host-gateway三种。目前，VXLAN是官方比较推崇的一种backend实现方式。

　　UDP模式和VXLAN模式基于三层网络层即可实现，而host-gateway模式就必须要求集群所有机器在同一个广播域，也就是需要在二层网络同一个交换机下才能实现。

　　host-gatewa一般用于对网络性能要求比较高的场景，但需要基础网络架构的支持；UDP则用于测试及一般比较老的不支持VXLAN的Linux内核。

　　1.UDP模式

　　采用UDP模式时，需要在flanneld的配置文件中指定Backend.Type为UDP，可通过直接修改flanneld的ConfigMap的方式实现。

# kubectl get cm kube-flannel-cfg -n kube-system -o yaml
 kubectl
   net-conf.json: |
    {
      "Network": "10.233.64.0/18",
      "Backend": {
        "Type": "udp"
      }
    }

　　通过ip addr 命令可以发现节点上会多出一个flannel 0的网络接口，在UDP模式中，flanneld的主要作用为：

　　（1）UDP包封包解包

　　（2）节点上路由表的动态更新

　　工作流程图：

　　熟悉Linux的应该知道，Linux频繁内核态-用户态的切换，会造成频繁的上下文切换，会引发性能问题，所以从上面可以看到container的数据包，从离开src container后，经过了多次内核态-用户态的切换，并且，数据包是由用户态的flannel进行进行封包/解包的，从而导致了比较大的性能损耗，这也是为什么生产基本不会用这个方案，因为性能实在非常差。

　　2.VXLAN模式

　　同样需要在Backend.Type修改为VXLAN

net-conf.json: |
    {
      "Network": "10.233.64.0/18",
      "Backend": {
        "Type": "vxlan"
      }
    }

　　VXLAN模式下，会创建一个名为flannel 1的VTEP设备，数据的转发由内核完成，并不是flanned，flanned仅动态设置ARP和FDB表项.

　　工作流程图:

　　vxlan本身就是内核特性，使用vxlan会在服务器中创建一个vtep设备(flannel 1)，设备的封包/解包操作都在该设备下操作，所以直接在内核态操作，不需要CPU上下文切换，且和UDP直接三层封包不一样，vxlan是直接对二层数据帧进行封包。

　　3.host-gateway模式

　　同上需要在Backend.Type修改为host-gw。

　　由于host-gw是纯路由模式，flannel需要通过etcd维护所有的静态路由,核心是IP包在封装成桢的时候，使用路由表的"下一跳"设置上的MAC地址，这样可以经过二层网络到达目的宿主机。这就要求所有的服务器在同一个二层网络下，这就使host-gw模式无法适用于集群规模较大且需要对节点进行网段划分的场景。

　　host-gw另外一个限制则是随着集群中节点规模的增大，flanneld维护主机上成千上万条路由表的动态更新也是一个不小的压力，因此在路由方式下，路由表规则的数量是限制网络规模的一个重要因素。

　　工作流程图：

　　在性能上，host-gw由于没有封包/解包，故性能最好