故障
问题和版本没关系,客户的 node 信息啥的后面排错里有。有个节点通信有问题,其余节点都没问题。
排查
惯例信息
先看下 flannel
的 vxlan
的 vtep
信息,客户是双网卡的,但是默认路由是这个网卡,不用管另外的网卡了。下面信息看了下 VtepMAC
和 public-ip
都正常。
1 | $ kubectl get node -o yaml | grep -B4 public |
coredns 的 pod ip 和 node 分布情况
1 | $ kubectl -n kube-system get pod -o wide |
排查
curl 下 coredns 的 metrics 接口试试,只有 10.25.1.51
和其他节点无法通信。会导致下面的 curl 卡住。
1 | curl 172.27.1.4:9153 |
目标机器 10.25.1.55
上通过 flannel.1 接口抓我们的 curl 包:
1 | $ tcpdump -nn -i flannel.1 host 172.27.1.4 and port 9153 -vv |
看着是回复了报文 172.27.1.4.9153 > 172.27.0.0.57888
,在我们 curl 的机器 10.25.1.51
上 lsof -nPi :57888
看到的确实是卡住的 curl 命令 pid 。10.25.1.51
上也同时抓包看下
1 | $ tcpdump -nn -i flannel.1 host 172.27.1.4 and port 9153 -vv |
没收到包,从 eth1
抓下 flannel
的 8475
端口(配置里我们改了 flannel 的端口)试试:
目标机器 10.25.1.55
上抓包
1 | $ tcpdump -nn -i eth1 host 10.25.1.51 and port 8475 -vvv |
目标机器 10.25.1.51
上抓包:
1 | $ tcpdump -nn -i eth1 host 10.25.1.55 and port 8475 -vvv |
完全没报文过来,看了下 flannel
的接口流量压根就没收到任何包:
1 | $ ifconfig flannel.1 |
说明报文从 10.25.1.55
发出后没到 51 上,让客户开通 udp 8475 10.25.1.0/24
整个段的东西向安全组后就正常了。
1 | $ curl 172.27.1.4:9153 |