flannel-vxlan模式原理解析

前言

上一章介绍完flannel的udp模式后，接着来介绍一下vxlan模式，因为很多生产的K8S都正在使用这个模式，所以将会介绍得详细些。

在前面的章节中，我们介绍过配置linux vxlan完成跨主机的容器通信，flannel的vxlan模式大概完成的事情就是把那个章节中手工完成的事情自动化了而已，想了解的童鞋可以看回那一章

linux配置跨主机容器通信

vxlan模式下的flannel比udp模式少了一个组件，就是用c语言写的打开tun设备的守护进程flanneld，因为vxlan模式下通信的全程都由linux内核完成，所以只剩下二进制的flannel文件和以k8s的daemonset的方式运行的kube-flannel这两个组件了，下面将详细介绍这两个组件以及他们如何与kubelet配合完成一个POD的网络编织。

二进制flannel文件

二进制flannel文件存放在每个节点的/opt/cni/bin目录下，这个目录下还有cni官方默认提供的其它插件，这些cni插件分为三类：

1. ipam，负责地址分配，主要有：host-local、dhcp、static

2. main，负责主机和容器网络的编织，主要有：bridge、ptp、ipvlan、macvlan、host-device、

3. meta，其它，主要有：flannel、bandwidth、firewall、portmap、tuning、sbr

这些文件是我们在安装kubeadm和kubelet时自动安装的，如果发现这个目录为空，也可以用下面的命令手动安装：

yum install kubernetes-cni -y

这个flannel文件不做具体的网络编织的工作，而是生成其它cni插件需要的配置文件，然后调用其它的cni插件（通常是bridge和host-local），完成主机内容器到主机的网络互通，事实上这个flannel文件的源码已经不在flannel项目上了，因为这个flannel文件已经是cni的默认组件之一了，所以它的源码在cni的plugins中，地址如下：

https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel

kubelet创建一个POD时，先会创建一个pause容器，然后用pause容器的网络命名空间文件路径为入参（类似：/var/run/docker/netns/xxxx，前面的文章讲过这个路径如何获取及使用），加上其它一些参数，调用/etc/cni/net.d/目录下的配置文件指定的cni插件，这个目录的配置文件是kube-flannel启动时复制进去的，内容如下：

cat /etc/cni/net.d/10-flannel.conflist
{
  "name": "cbr0",
  "cniVersion": "0.3.1",
  "plugins": [
    {
      "type": "flannel",
      "delegate": {
        "hairpinMode": true,
        "isDefaultGateway": true
      }
    },
    {
      "type": "portmap",
      "capabilities": {
        "portMappings": true
      }
    }
  ]
}

这个文件中指定的cni插件叫flannel，于是就调用了/opt/cni/bin/flannel文件，这个文件先会读取/run/flannel/subnet.env文件，这个文件也是kube-flannel启动时写入的，里面主要包含当前节点的子网信息，内容如下：

cat /run/flannel/subnet.env

FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.1.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=true

flannel读取该文件内容后，紧接着会生成一个符合cni标准的配置文件，内容如下：

{
  "cniVersion": "0.3.0",
  "name": "networks",
  "type": "bridge",
  "bridge": "cni0",
  "isDefaultGateway": true,
  "ipam": {
    "type": "host-local",
    "subnet": "10.244.1.0/24",
    "dataDir": "/var/lib/cni/",
    "routes": [{ "dst": "0.0.0.0/0" }]
  }
}

然后像kubelet调用flannel的方式一样调用另一个cni插件bridge，并把上面的配置文件的内容用标准输入的方式传递过去，调用方式如下：

echo '{ "cniVersion": "0.3.0", "name": "network", "type":"bridge","bridge":"cni0", "ipam":{"type":"host-local","subnet": "10.244.1.0/24","dataDir": "/var/lib/cni/","routes": [{ "dst": "0.0.0.0/0" }]}}' | CNI_COMMAND=ADD 
CNI_CONTAINERID=xxx 
CNI_NETNS=/var/run/docker/netns/xxxx 
CNI_IFNAME=xxx 
CNI_ARGS='IgnoreUnknown=1;K8S_POD_NAMESPACE=applife;K8S_POD_NAME=redis-59b4c86fd9-wrmr9' 
CNI_PATH=/opt/cni/bin/ 
./bridge

剩余的工作就会由/opt/cni/bin/bridge插件完成，它会在主机上创建一个cni0的linux bridge，然后创建一条主机路由，并创建一对Veth网卡，把一端插到新创建的POD，另一端插到网桥上，这些内容我们在前面的文章中介绍过，感兴趣的童鞋可以看回：

理解linux虚拟网络设备bridge

host-local是以写本地文件的方式来标识哪些IP已经被占用，它会在/var/lib/cni/network/host-local/（这个目录其实是上面的dataDir参数指定的）目录下生成一些文件，文件名为已分配的IP，文件内容为使用该IP的容器ID，有一个指示当前已分配最新的IP的文件。

kube-flannel

kube-flannel以k8s的daemonset方式运行，启动后会完成以下几件事情：

1. 启动容器会把/etc/kube-flannel/cni-conf.json文件复制到/etc/cni/net.d/10-flannel.conflist：这个文件是容器启动时从配置项挂载到容器上的，可以通过修改flannel部署的yaml文件来修改配置，选择使用其它的cni插件。

2. 运行容器会从api-server中获取属于本节点的pod-cidr，然后写一个配置文件/run/flannel/subnet.env给二进制的flannel用

3. 创建一个名为flannel.1的vxlan设备，把这个设备的MAC地址和IP以及本节点的IP记录到ETCD。

4. 启动一个进程，不断地检查本机的路由信息是否被删除，如果检查到缺失，则重新创建，防止误删导致网络不通的情况。

5. 最后会通过api-server或etcd订阅关于节点信息变化的事件

接下来介绍一下当kube-flannel收到节点新增事件时会完成的事情，假设现在有一个k8s集群拥有master、node1和node2三个节点，这时候新增了一个节点node3，node3的IP为：192.168.3.10，node3上的kube-flannel为node3创建的vxlan设备IP地址为10.244.3.0，mac地址为：02:3f:39:67:7d:f9 ，相关的信息保存在节点的注解上，用kubectl查看node3的节点信息如下：

[root@node1]# kubectl describe node node3
Name:               node3
...
Annotations:        flannel.alpha.coreos.com/backend-data: {"VtepMAC":"02:3f:39:67:7d:f9"}
										flannel.alpha.coreos.com/backend-type: vxlan
										flannel.alpha.coreos.com/kube-subnet-manager: true
										flannel.alpha.coreos.com/public-ip: 192.168.3.10
...
PodCIDR: 10.244.3.0/24

node1上的kube-flannel收到node3的新增事件，会完成以下几件事：

1. 新增一条到10.244.3.0/24的主机路由，并指明通过flannel.1设备走，下一跳为node3上的vxlan设备地址：

ip route add 10.244.3.0/24 via 10.244.3.0 dev flannel.1 onlink

1. 新增一条邻居表信息，指明node3的vxlan设备10.244.3.0的mac地址为：02:3f:39:67:7d:f9,并用nud permanent指明该arp记录不会过期，不用做存活检查：

ip neigh add 10.244.3.0 lladdr 02:3f:39:67:7d:f9 dev flannel.1 nud permanent

1. 新增一条fdb（forwarding database)记录，指明到node3的vxlan设备的mac地址的下一跳主机为node3的ip：

bridge fdb append  02:3f:39:67:7d:f9 dev vxlan0 dst 192.168.3.10 self permanent

如果在配置中启用了Directrouting，那么在这里会判断新增节点与当前节点是否在同一子网，如果是，则直接新建一条主机路由，前面三步都不会发生，取而代之的是：

ip route add 10.244.3.0/24 via 192.168.3.10 dev eth0 onlink

这就是host-gw下增加的主机路由，也是我们前面介绍过的。

下面我们通过一个例子来介绍一下上面新增的这些记录的实际用途，假设node1上有个pod1，IP为10.244.1.3；node3上有个pod2，pod2的IP为10.244.3.3，来看一下在vxlan模式下从pod1到pod2的数据包发送与接收的过程。

发送

1.数据包从pod1出来，到达node1的协议栈，经过路由判决，走node1的forward链。

2.forward时，要去的pod2的IP为10.244.3.3,主机路由匹配到应该走flannel.1,下一跳为10.244.3.0（节点新增时，添加的主机路由）

3.数据包到达flannel.1设备，它发现下一跳的地址为10.244.3.0，于是它先会查找10.244.3.0的mac地址，在arp表中找到了匹配的记录为02:3f:39:67:7d:f9（上面节点新增时，步骤二添加的ARP记录在这里就用上了）,然后完成mac头封装，准备发送。

4.因为是vxlan设备，发送方法与普通的网卡有些区别（详见下面的代码vxlan_xmit），数据包也没有被提交到网卡的发送队列，而是由vxlan设备进一步封装成一个udp数据包，它会根据目标mac地址来反查下一跳的主机地址以决定把这个udp数据包发给哪个主机，这时候就会用到上面提到的fdb表了，它查到去往02:3f:39:67:7d:f9的下一跳主机地址为192.168.3.10（节点新增时，步骤三添加的FDB记录）,于是封装udp包，走ip_local_out，发往node3 。

// linux-4.18\drivers\net\vxlan.c

static netdev_tx_t vxlan_xmit(struct sk_buff *skb, struct net_device *dev)
{
    ...
    //取链路层头部
    eth = eth_hdr(skb);
    // 根据目标mac地址查找fdb表项
    f = vxlan_find_mac(vxlan, eth->h_dest, vni);
    ...
    vxlan_xmit_one(skb, dev, vni, fdst, did_rsc);
}

static void vxlan_xmit_one(struct sk_buff *skb, struct net_device *dev,
               __be32 default_vni, struct vxlan_rdst *rdst,
               bool did_rsc)
{
...
        // 封装vxlan头
        err = vxlan_build_skb(skb, ndst, sizeof(struct iphdr),
                      vni, md, flags, udp_sum);
        if (err < 0)
            goto tx_error;
        
        // 封装UDP头、外部IP头，最后走ip_local_out
        udp_tunnel_xmit_skb(rt, sock4->sock->sk, skb, local_ip.sin.sin_addr.s_addr,
                    dst->sin.sin_addr.s_addr, tos, ttl, df,
                    src_port, dst_port, xnet, !udp_sum);
...
}

接收

1. node3接收后，走主机协议栈，判断这是发往本机的udp包，于是走INPUT方向，最终发到UDP层处理。

2. 当我们创建vxlan UDP套接字的时候，会为其encap_rcv覆值vxlan_rcv，所以在收到vxlan的UDP报文后，会调用vxlan_rcv处理，vxlan_rcv做的事情就是剥去vxlan头，将内部的一个完整的二层包重新送入主机协议栈。

3. 剥去vxlan头部后的包重新来到主机协议栈，此时包的目标地址是10.244.3.3，经过路由判决时，发现不是本机地址，走FORWARD方向，找到合适的路由，最终发往pod2。

// linux-4.18\drivers\net\vxlan.c

//创建vxlan设备时，会调用vxlan_open -> vxlan_sock_add -> __vxlan_sock_add -> vxlan_socket_create

static struct vxlan_sock *vxlan_socket_create(struct net *net, bool ipv6,
                          __be16 port, u32 flags)
{
...
    tunnel_cfg.encap_rcv = vxlan_rcv;   //这是最关键的点，收包的时候，会把vxlan的包给vxlan_rcv处理
...
}

//udp包接收方法，如果是vxlan相关的包，会给vxlan_rcv处理
static int udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
{
...
            //这里就会把包给到vxlan_rcv处理
            ret = encap_rcv(sk, skb);
...
}

/* Callback from net/ipv4/udp.c to receive packets */
static int vxlan_rcv(struct sock *sk, struct sk_buff *skb)
{
    //剥vxlan头    
    if (__iptunnel_pull_header(skb, VXLAN_HLEN, protocol, raw_proto,
                   !net_eq(vxlan->net, dev_net(vxlan->dev))))
            goto drop;
            
     ...
     gro_cells_receive(&vxlan->gro_cells, skb);
     ...
}

int gro_cells_receive(struct gro_cells *gcells, struct sk_buff *skb)
{
    ...
    
    if (!gcells->cells || skb_cloned(skb) || netif_elide_gro(dev))
        //非NAPI收包处理，linux虚拟网络设备接收如果需要软中断触发通常会走这里
        return netif_rx(skb);
    ...
}

0.9.0之前的版本

特别介绍一下flannel在0.9.0版本之前，用的策略完全不一样，kube-flannel不会在新增节点的时候就增加arp表和fdb表，而是在数据包传递的过程中，需要用到某个ip的arp地址但没有找到时会发送一个l3miss的消息（RTM_GETNEIGH）给用户态的进程，让用户进程补齐arp记录； 在封装udp包时，在fdb表找不到mac的下一跳主机记录时，发送一个l2miss消息给用户态进程，让用户态的进程补齐fdb记录，让流程接着往下走。

它启动时会打开下面的标志位：

echo 3 > /proc/sys/net/ipv4/neigh/flannel.1/app_solicit

这样vxlan在封包过程中如果缺少arp记录和fdb记录就会往用户进程发送消息

从0.9.0版本开始，flannel取消了监听netlink消息：

https://github.com/coreos/flannel/releases/tag/v0.9.0

总结

可以看出，从0.9.0版本后的flannel在vxlan模式下，容器的通信完全由linux内核完成，已经不用kube-flannel参与了，这就意味着，哪怕在运行的过程中，kube-flannel挂掉了，也不会影响现有容器的通信，只会影响新加入的节点和新创建的容器。