flannel vxlan工作基本原理及常见排障方法

2019-06-11 17:52:41 阅读：309 来源： 互联网

标签：cni0 排障 0.0 flannel.1 10.244 ff 10.10 vxlan flannel

写在前面

最近用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 发送数据包为例。

flannel

10.244.0.6容器在节点10.10.10.216。我们可以通过ip add命令查看到容器在物理机上的veth卡。

[root@node-64-216 ~]# ip add
2: 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 forever
23: 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 forever
24: 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 forever
29: 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 show
bridge name bridge id       STP enabled interfaces
cni0        8000.eeb29e95af9d   no      vethb547248d
                            vethe527455b
                            vetheb3a1d6b

数据包走到了cni0的网桥后，根据已经的目标ip，10.244.1.2，可以查找路由表，根据路由和掩码，选择对应的iface，也就是flannel.1。且下一跳，也就是10.244.1.0。

[root@node-64-216 ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.10.10.1       0.0.0.0         UG    0      0        0 em1
10.10.10.0       0.0.0.0         255.255.255.0   U     0      0        0 em1
10.244.0.0      0.0.0.0         255.255.255.0   U     0      0        0 cni0
10.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 -e
Address                  HWtype  HWaddress           Flags Mask            Iface
10.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 show
3e: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 add
2: 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 forever
152: 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 forever
153: 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 forever
154: 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 -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.10.10.1       0.0.0.0         UG    0      0        0 em1
10.10.10.0       0.0.0.0         255.255.255.0   U     0      0        0 em1
10.244.0.0      10.244.0.0      255.255.255.0   UG    0      0        0 flannel.1
10.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 interfaces
cni0        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导致的。

参考资料

vxlan 协议原理简介 https://cizixs.com/2017/09/25/vxlan-protocol-introduction/
VXLAN技术研究 https://blog.csdn.net/sinat_31828101/article/details/50504656
Flannel中vxlan backend的原理和实现 http://dockone.io/article/2216

标签：cni0,排障,0.0,flannel.1,10.244,ff,10.10,vxlan,flannel
来源： https://www.cnblogs.com/xuxinkun/p/11003375.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9

flannel vxlan工作基本原理及常见排障方法

写在前面

容器间通信

排障的主要思路

参考资料