最近用kubeadm鼓捣了几个cluster集群测试用，网络用的flannel。因为这些机器都不是纯净的环境（以前部署过其他的k8s或者有一些特别的设置），所以部署起来遇到了很多问题。看了下相关的文章，梳理了flannel的vxlan的工作原理，成功对这几个环境进行了排障。本文主要是相关流程的笔记记录。
本文以两个节点上的两个容器间通信为例，介绍网络报文的流转过程以及可能出现的问题。
flannel使用的镜像为quay.io/coreos/flannel:v0.11.0-amd64
我现在部署有两个node节点，节点ip为10.10.10.216和10.10.10.217。本文将以这两个节点上的容器为例。介绍两个容器是如何通讯的。
| 节点 | 容器IP段 | 容器IP |
|---|---|---|
| 10.10.10.216 | 10.244.0.0/24 | 10.244.0.6 |
| 10.10.10.217 | 10.244.1.0/24 | 10.244.1.2 |
首先讲下 10.244.0.6 和 10.244.1.2 两个容器间的通信流程。我们这里以从10.244.0.6向10.244.1.2 发送数据包为例。
10.244.0.6容器在节点10.10.10.216。我们可以通过ip add命令查看到容器在物理机上的veth卡。
[root@node-64-216 ~]# ip add2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether e0:db:55:13:7a:74 brd ff:ff:ff:ff:ff:ff inet 10.10.10.216/24 brd 10.10.10.255 scope global em1 valid_lft forever preferred_lft forever23: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default link/ether 8a:28:fa:8e:8c:4b brd ff:ff:ff:ff:ff:ff inet 10.244.0.0/32 scope global flannel.1 valid_lft forever preferred_lft forever24: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000 link/ether ee:b2:9e:95:af:9d brd ff:ff:ff:ff:ff:ff inet 10.244.0.1/24 scope global cni0 valid_lft forever preferred_lft forever29: vethb547248d@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP group default link/ether 8e:f6:51:f5:9b:a3 brd ff:ff:ff:ff:ff:ff link-netnsid 2因为这里使用了cni接口标准，这个veth卡会桥接在cni0的网桥上。这个我们可以通过brctl show进行查看。
[root@node-64-216 ~]# brctl showbridge name bridge id STP enabled interfacescni0 8000.eeb29e95af9d no vethb547248d vethe527455b vetheb3a1d6b数据包走到了cni0的网桥后，根据已经的目标ip，10.244.1.2，可以查找路由表，根据路由和掩码，选择对应的iface，也就是flannel.1。且下一跳，也就是10.244.1.0。
[root@node-64-216 ~]# route -nKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface0.0.0.0 10.10.10.1 0.0.0.0 UG 0 0 0 em110.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 em110.244.0.0 0.0.0.0 255.255.255.0 U 0 0 0 cni010.244.1.0 10.244.1.0 255.255.255.0 UG 0 0 0 flannel.1进入到flannel.1如何知道应该发向哪个物理机呢。这个时候，其实是通过arp来获取。可以通过arp命令查看到对应的mac地址。
[root@node-64-216 ~]# arp -eAddress HWtype HWaddress Flags Mask Iface10.244.1.0 ether 3e:01:ed:47:de:7f CM flannel.1这个mac地址在vxlan中，可以通过bridge fdb show来进行查看。可以看到，如果是发向3e:01:ed:47:de:7f的地址，则目标机器在10.10.10.217机器上。则数据就会流转到10.10.10.217上了。经过vxlan封包后的数据包就会经过em1设备发向到10.10.10.217上。
[root@node-64-216 ~]# bridge fdb show3e:01:ed:47:de:7f dev flannel.1 dst 10.10.10.217 self permanent在10.10.10.217上，首先经过了iptables链，而后在flannel.1的Iface上则接收到该数据包。这里我们可以看到，flannel.1的mac地址就是3e:01:ed:47:de:7f。
这里我曾经就是遇到过被iptables的forward链拦住的情况。如果数据包在216的flannel.1上可以监测到，但是217的flannel.1中断了，则可以检查216到217之间的路由情况以及217的iptables链的情况。
[root@node-64-217 ~]# ip add2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 90:b1:1c:33:b4:b1 brd ff:ff:ff:ff:ff:ff inet 10.10.10.217/24 brd 10.10.10.255 scope global em1 valid_lft forever preferred_lft forever152: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default link/ether 3e:01:ed:47:de:7f brd ff:ff:ff:ff:ff:ff inet 10.244.1.0/32 scope global flannel.1 valid_lft forever preferred_lft forever153: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000 link/ether 36:11:ab:93:2f:6f brd ff:ff:ff:ff:ff:ff inet 10.244.1.1/24 scope global cni0 valid_lft forever preferred_lft forever154: veth7f8b8e9e@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP group default link/ether 06:2f:35:74:cd:de brd ff:ff:ff:ff:ff:ff link-netnsid 0到达flannel.1后，根据路由表，查看10.244.1.2的路由应送到217的cni0的网桥上。
[root@node-64-217 ~]# route -nKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface0.0.0.0 10.10.10.1 0.0.0.0 UG 0 0 0 em110.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 em110.244.0.0 10.244.0.0 255.255.255.0 UG 0 0 0 flannel.110.244.1.0 0.0.0.0 255.255.255.0 U 0 0 0 cni0这里我们查看cni0的网桥信息。
[root@node-64-217 ~]# brctl show bridge name bridge id STP enabled interfacescni0 8000.3611ab932f6f no veth5a89e906 veth7f8b8e9e到达网桥后，就可以根据地址将数据送到10.244.1.2的对应的veth上，进而在容器中收到对应的数据包了。
以上就是两个处于不同物理机上的容器间发送数据包的流程。相比较来说，从容器到物理机的ping就简单多了。这个流程就是veth->cni0->em1->对端物理机ip。这里就不详细叙述了。
同一台物理机上不同容器的ping只需要经过cni0的网桥就可以了。
在梳理了数据包的正常流转过程后，就可以用tcpdump来进行问题的定位，进而排查出哪个环节出现了问题，进而查看问题产生的原因。
还是以两个物理机上的两个容器之间的通信为例，可以从一个容器向另一个容器进行ping，然后使用tcpdump分别在发起ping的容器的物理机上抓cni0，flannel.1，以及目标容器的物理机上抓flannel.1，cni0上进行抓包。看看是在哪个环节丢失的数据包。
比如在发起ping的物理机的cni0上有数据包，但是发起ping的物理机的flannel.1上没有，则可能路由发生了问题，需要查看路由表。
又比如前文中提到过的在发起ping的容器的物理机上flannel.1上可以抓到数据包，但是在目标容器的物理机的flannel.1上抓不到，则可能是二者之间的路由问题或者iptables导致的。
联系客服
