Flannel VXLAN 通信异常问题排障记录

2022-11-21 10:07:35 浏览数 (4)

现象

rancher 所在 k8s 集群(local 集群)间歇性挂,而其纳管的另一个生产 k8s 集群没有这个问题。

rancher 的 3 台服务器 rancher1(172.16.1.194)、rancher2(172.16.1.195)、rancher3(172.22.1.199)

注意到 rancher3 和 rancher1/2 不在一个网段。

排查

经过排查发现以下几个现象:

  1. 浏览器不访问 rancher 没有事,访问一会儿就挂。
  2. 挂的时候 etcd 集群不健康,存在 leader 丢失 ,节点间通信异常,查询响应缓慢(100ms~20s)

1

docker logs --tail 500 -f etcd

  1. 挂的时候,tcpdump etcd 2380 端口,发现大量连接重置错误

1

docker logs --tail 500 -f etcd

  1. 挂的时候,ping rancher2->rancher3 正常,但是 rancher3->rancher2 不正常。
  2. 挂的时候,traceroute rancher2->rancher3 正常,但是 rancher3->rancher2 不正常。
  3. 挂的时候,rancher3 同子网其他机器 ping rancher2 正常。
  4. 挂的时候,rancher1/2 etcd cluster-health 看到rancher3 unhealthy,

rancher3 etcd cluster-health 看到 rancher1/2 dial 不通,然后看到自己 unhealthy。

恢复的时候,和 ping 一样,rancher 1/2 看到 rancher3 healthy,但是 rancher3 看到的问题依旧。

1 2 3 4 5 6

etcdctl --cert-file /etc/kubernetes/ssl/kube-etcd-<ip>.pem --key-file /etc/kubernetes/ssl/kube-etcd-<ip>-key.pem --ca-file /etc/kubernetes/ssl/kube-ca.pem --endpoint https://localhost:2379 cluster-health

7.1)重装了 rancher3 操作系统,问题依旧

7.2)修改集群模式,当只有 rancher3 一个节点,没有什么问题

7.3)修改集群模式,rancher3 作为 master,rancher1/2 作为 worker,问题依旧

8)分别在 rancher1 和 3 上抓 flannel 8472 端口的包:

1

tcpdump -i ens160 -nn 'udp and port 8472' -w udp.pcap

然后用 wireshark 分析,发现 rancher3 上有时间跨度 90s 的包收发,rancher1 上只有 33s 的包收发,说明传输过程中数据丢失了。

flannel 用的是 UDP 协议,而传输问题出在 UDP 协议上,那么可以推测数据包超过某个大小时,故障就会发生。

9)测试 UDP 传输

在 rancher1 上启动 nc 监听 UDP 端口

1

nc -u -l -p 8888

在 rancher3 上同样用 nc 传输数据,经过测试发现,1472 字节是单次传输的最大尺寸了,超过这个尺寸 rancher1 就收不到了。

1

nc -u rancher1 8888 < 1473.log

而在 rancher2 上,传输一个 10M 的文件都没有问题。

注意:nc 在做过一次传输之后,服务端要重启,因为 nc 一次只能接收一个连接,要关掉重开才行。

10)虽然测出了超出 1472 字节的 UDP 数据传不过去,但是这时 rancher3 ping rancher1 依然是通的。

推测和流量有关,必须 UDP 流量达到一定程度,才会阻断 rancher3 -> rancher1 的所有通信。

在 rancher1 上启动 iperf3 服务端:

1

iperf3 -s

在 rancher3 上启动 iperf3 压测(流量 22100Kbit/sec)

1

iperf3 -c rancher1 -u -b 22100K

然后 rancher3 -> rancher1 就不通了,ping 也不通。

另外发现,rancher3 -> rancher1 ping 不通的时候,ping rancher2 也不同,实际上是阻断了 rancher3 -> 172.16.1.0/24 网段的所有流量。

结论

还是网络问题,UDP 流量稍大点的时候,某个触发了某个网络设备限流策略。

1 人点赞