Kubernetes网络故障排查实战之旅( 四 ) _Kubernetes

vxlan隧道设置看起来正常。它显示了远程端点IP 192.168.10.163，这是工作节点虚拟机的IP 。
此外，pod虚拟机中没有防火墙规则。
但是，你没有看到像在工作节点上一样的veth对。现在，浮现的一个问题是，没有veth对， init和podns网络命名空间之间如何进行通信。请注意，物理设备在init(root)命名空间中，vxlan设备在podns网络命名空间中。
感谢Stefano Brivio指出了使这种情况发生的Linux内核提交。
commit f01ec1c017dead42092997a2b8684fcab4cbf126Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>Date: Thu Apr 24 10:02:49 2014 +0200vxlan: add x-netns supportThis patch allows to switch the netns when packet is encapsulated or decapsulated. The vxlan socket is openned into the i/o netns, ie into the netns where encapsulated packets are received. The socket lookup is done into this netns to find the corresponding vxlan tunnel. After decapsulation, the packet is injecting into the corresponding interface which may stand to another netns.When one of the two netns is removed, the tunnel is destroyed.Configuration example: ip netns add netns1 ip netns exec netns1 ip link set lo up ip link add vxlan10 type vxlan id 10 group 239.0.0.10 dev eth0 dstport 0 ip link set vxlan10 netns netns1 ip netns exec netns1 ip addr add 192.168.0.249/24 broadcast 192.168.0.255 dev vxlan10 ip netns exec netns1 ip link set vxlan10 up这也有一个StackOverflow主题对此进行了解释。
这些细节为我们提供了对pod虚拟机网络拓扑的良好概述，如下图所示。

文章插图
让我们在vxlan0接口上运行tcpdump ，看ICMP请求是否从工作节点接收。
如下输出所示，ICMP请求已接收，但没有响应。

root@podvm-nginx-priv-8b726648:/home/ubuntu# ip netns exec podns tcpdump -i vxlan0 -s0 -n -vvtcpdump: listening on vxlan0, link-type EN10MB (Ethernet), capture size 262144 bytes[snip]10.132.2.2 > 10.132.2.46: ICMP echo request, id 20, seq 1, length 6410:34:17.389643 IP (tos 0x0, ttl 64, id 27606, offset 0, flags [DF], proto ICMP (1), length 84)10.132.2.2 > 10.132.2.46: ICMP echo request, id 20, seq 2, length 6410:34:18.413682 IP (tos 0x0, ttl 64, id 27631, offset 0, flags [DF], proto ICMP (1), length 84)10.132.2.2 > 10.132.2.46: ICMP echo request, id 20, seq 3, length 6410:34:19.002837 IP (tos 0x0, ttl 1, id 28098, offset 0, flags [DF], proto UDP (17), length 69)[snip]

现在，让我们总结一下情况。
通过这个练习，你对工作节点和pod虚拟机的网络拓扑有了很好的理解，隧道的设置看起来也没有问题。你也看到ICMP数据包被pod虚拟机接收，没有软件防火墙阻止数据包。那么下一步该做什么?
继续阅读以了解下一步该做什么:-)
故障排查 - 第二阶段我使用wireshark分析了来自工作正常(常规Kata)设置的tcpdump捕获。Wireshark图形界面可以方便地理解通过tcpdump捕获的网络跟踪。
在跟踪中没有观察到ARP请求和响应。但是，工作节点上的ARP表被填充，ARP表使用pod网络命名空间中的eth0设备的mac(在工作节点上)，而不是pod虚拟机上的podns命名空间中的vxlan0设备的MAC 。
? (10.132.2.46) at 0a:58:0a:84:02:2e [ether] on ovn-k8s-mp00a:58:0a:84:02:2e是工作节点上pod网络命名空间中eth0接口的MAC，而7e:e5:f7:e6:f5:1a是pod虚拟机上podns命名空间中的vxlan0接口的MAC 。
这是问题的原因 - 从工作节点无法访问pod IP 。ARP条目应指向pod虚拟机上podns命名空间中的vxlan0设备的MAC(即7e:e5:f7:e6:f5:1a) 。

事后看来，我本该首先查看ARP表条目。下次遇到类似问题我一定会这么做;)

解决方案Stefano Brivio的一个小技巧解决了这个问题。在pod虚拟机的vxlan0接口上使用与工作节点上pod的eth0接口相同的MAC地址可以解决连接问题。

ip netns exec podns ip link set vxlan0 downip netns exec podns ip link set dev vxlan0 address 0a:58:0a:84:02:2eip netns exec podns ip link set vxlan0 up

最终的网络拓扑结构如下所示。