Kubernetes網絡故障排查實戰之旅

作者：岱軍 2023-11-10 07:23:57

調試Kubernetes集群中的網絡問題并非易事。然而，通過明確的方法、專家的幫助和公開可用的資料，找到根本原因和修復問題是可能的。在這個過程中獲得樂趣并掌握知識。

在開發Kata/remote-hypervisor(也稱為peer-pods)方案時，我遇到了一個問題，即Kubernetes pod IP在工作節點上無法訪問。在本博客中，我將描述Kubernetes網絡故障排查過程，希望對讀者有幫助。

譯自A Hands-on Kubernetes Network Troubleshooting Journey。

Kata遠程管理程序(peer-pods)方案通過在AWS或Microsoft Azure等基礎設施環境中使用本機基礎設施管理API(如在AWS上創建Kata VM時使用AWS API，在Azure上創建時使用Microsoft Azure API)，實現在任何基礎設施環境中創建Kata VM。CNCF保密容器項目的cloud-api-adaptor子項目實現了Kata遠程管理程序。

如下圖所示，在peer-pods方案中，pod(Kata)虛擬機在Kubernetes(K8s)工作節點外部運行，通過VXLAN隧道從工作節點訪問pod IP。使用隧道可以確保pod聯網繼續正常工作，無需對CNI網絡做任何改變。

圖片

當使用Kata容器時，Kubernetes pod在虛擬機內運行，因此我們將運行pod的虛擬機稱為Kata VM或pod虛擬機。

問題

pod IP10.132.2.46，它位于pod虛擬機上(IP:192.168.10.201)，從工作節點虛擬機(IP:192.168.10.163)無法訪問。

以下是我環境中的虛擬機詳細信息 —— 工作節點虛擬機和pod(Kata)虛擬機。使用的Kubernetes CNI是OVN-Kubernetes。

+===========================+================+================+
|          VM名稱           |   IP地址       |     備注       |
+===========================+================+================+
| ocp-412-ovn-worker-1      | 192.168.10.163 | 工作節點虛擬機 |
+---------------------------+----------------+----------------+
| podvm-nginx-priv-8b726648 | 192.168.10.201 | Pod虛擬機      |
+---------------------------+----------------+----------------+

最簡單的解決方案就是請網絡專家來解決這個問題。然而，在我的情況下，由于其他緊迫問題，專家無法直接參與解決。此外，peer-pods網絡拓撲結構還比較新，涉及多個網絡棧 —— Kubernetes CNI、Kata網絡和VXLAN隧道，使得根本原因難以查明且非常耗時。

因此，我將這種情況視為提高我的Kubernetes網絡技能的機會。在一些Linux網絡核心專家的指導下，我開始自行調試。

在后續章節中，我將通過我的方法帶您逐步了解調試過程和找到問題根本原因。我希望這個過程能對Kubernetes網絡問題故障排除有所幫助。

故障排查 - 第一階段

在高層面上，我采取的方法包含以下兩個步驟:

了解網絡拓撲結構
從拓撲結構中識別有問題的部分

讓我們從工作節點虛擬機ping IP:10.132.2.46，并跟蹤網絡棧中的流量:

[root@ocp-412-worker-1 core]# ping 10.132.2.46

Linux會參考路由表來確定發送數據包的目的地。

[root@ocp-412-worker-1 core]# ip route get 10.132.2.46
10.132.2.46 dev ovn-k8s-mp0 src 10.132.2.2 uid 0

因此，到pod IP的路由是通過設備ovn-k8s-mp0

讓我們獲取工作節點網絡詳細信息，并檢索有關ovn-k8s-mp0設備的信息。

[root@ocp-412-ovn-worker-1 core]# ip r
default via 192.168.10.1 dev br-ex proto dhcp src 192.168.10.163 metric 48
10.132.0.0/14 via 10.132.2.1 dev ovn-k8s-mp0
10.132.2.0/23 dev ovn-k8s-mp0 proto kernel scope link src 10.132.2.2
169.254.169.0/29 dev br-ex proto kernel scope link src 169.254.169.2
169.254.169.1 dev br-ex src 192.168.10.163 mtu 1400
169.254.169.3 via 10.132.2.1 dev ovn-k8s-mp0
172.30.0.0/16 via 169.254.169.4 dev br-ex mtu 1400
192.168.10.0/24 dev br-ex proto kernel scope link src 192.168.10.163 metric 48




[root@ocp-412-ovn-worker-1 core]# ip a


[snip]


2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master ovs-system state UP group default qlen 1000
    link/ether 52:54:00:f9:70:58 brd ff:ff:ff:ff:ff:ff
3: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 32:7c:7a:20:6e:5a brd ff:ff:ff:ff:ff:ff
4: genev_sys_6081: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65000 qdisc noqueue master ovs-system state UNKNOWN group default qlen 1000
    link/ether 3a:9c:a8:4e:15:0c brd ff:ff:ff:ff:ff:ff
    inet6 fe80::389c:a8ff:fe4e:150c/64 scope link
       valid_lft forever preferred_lft forever
5: br-int: <BROADCAST,MULTICAST> mtu 1400 qdisc noop state DOWN group default qlen 1000
    link/ether d2:b6:67:15:ef:06 brd ff:ff:ff:ff:ff:ff
6: ovn-k8s-mp0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether ee:cb:ed:8e:f9:e0 brd ff:ff:ff:ff:ff:ff
    inet 10.132.2.2/23 brd 10.132.3.255 scope global ovn-k8s-mp0
       valid_lft forever preferred_lft forever
    inet6 fe80::eccb:edff:fe8e:f9e0/64 scope link
       valid_lft forever preferred_lft forever
8: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 52:54:00:f9:70:58 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.163/24 brd 192.168.10.255 scope global dynamic noprefixroute br-ex
       valid_lft 2266sec preferred_lft 2266sec
    inet 169.254.169.2/29 brd 169.254.169.7 scope global br-ex
       valid_lft forever preferred_lft forever
    inet6 fe80::17f3:957b:5e8d:a4a6/64 scope link noprefixroute
       valid_lft forever preferred_lft forever


[snip]

從上述輸出可以看出，ovn-k8s-mp0接口的IP是10.132.2.2/23

讓我們獲取ovn-k8s-mp0接口的設備詳細信息。

如下輸出所示,這個接口是一個OVS實體。

[root@ocp-412-ovn-worker-1 core]# ip -d li sh dev ovn-k8s-mp0
6: ovn-k8s-mp0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/ether ee:cb:ed:8e:f9:e0 brd ff:ff:ff:ff:ff:ff promiscuity 1 minmtu 68 maxmtu 65535
openvswitch addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535

ovn-k8s-mp0是一個OVS橋嗎？

從下面的命令輸出可以清楚看到，ovn-k8s-mp0不是一個OVS橋。工作節點上存在的只有兩個橋:br-ex和br-int

[root@ocp-412-ovn-worker-1 core]# ovs-vsctl list-br
br-ex
br-int

所以ovn-k8s-mp0是一個OVS端口。我們需要找出擁有這個端口的OVS橋。

從下面的命令輸出可以清楚看到，ovn-k8s-mp0不是橋br-ex的OVS端口。

[root@ocp-412-ovn-worker-1 core]# ovs-ofctl dump-ports br-ex ovn-k8s-mp0
ovs-ofctl: br-ex: unknown port `ovn-k8s-mp0`

從下面的命令輸出可以清楚看到，ovn-k8s-mp0是一個OVS橋br-int的端口。

[root@ocp-412-ovn-worker-1 core]# ovs-ofctl dump-ports br-int ovn-k8s-mp0
OFPST_PORT reply (xid=0x4): 1 ports
port "ovn-k8s-mp0": rx pkts=1798208, bytes=665641420, drop=2, errs=0, frame=0, over=0, crc=0tx pkts=2614471, bytes=1357528110, drop=0, errs=0, coll=0

總結一下，ovn-k8s-mp0是一個br-int** OVS橋上的端口。它也持有橋的IP，即**10.132.2.2/23

現在，讓我們獲取pod的網絡配置詳細信息。

必須知道pod網絡命名空間才能確定pod網絡詳細信息。下面的命令通過IP找到pod網絡命名空間。

[root@ocp-412-ovn-worker-1 core]# POD_IP=10.132.2.46; for ns in $(ip netns ls | cut -f 1 -d " "); do ip netns exec $ns ip a | grep -q $POD_IP; status=$?; [ $status -eq 0 ] && echo "pod namespace: $ns" ; done


pod namespace: c16c7a01-1bc5-474a-9eb6-15474b5fbf04

一旦知道了pod網絡命名空間，就可以找到pod的網絡配置詳細信息，如下所示。

[root@ocp-412-ovn-worker-1 core]# NS=c16c7a01–1bc5–474a-9eb6–15474b5fbf04
[root@ocp-412-ovn-worker-1 core]# ip netns exec $NS ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
 inet6 ::1/128 scope host
 valid_lft forever preferred_lft forever
2: eth0@if4256: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP group default qlen 1000
 link/ether 0a:58:0a:84:02:2e brd ff:ff:ff:ff:ff:ff link-netns 59e250f6–0491–4ff4-bb22-baa3bca249f6
 inet 10.132.2.46/23 brd 10.132.3.255 scope global eth0
 valid_lft forever preferred_lft forever
 inet6 fe80::858:aff:fe84:22e/64 scope link
 valid_lft forever preferred_lft forever
4257: vxlan1@if4257: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
 link/ether ca:40:81:86:fa:73 brd ff:ff:ff:ff:ff:ff link-netns 59e250f6–0491–4ff4-bb22-baa3bca249f6
 inet6 fe80::c840:81ff:fe86:fa73/64 scope link
 valid_lft forever preferred_lft forever




[root@ocp-412-ovn-worker-1 core]# ip netns exec $NS ip r
default via 10.132.2.1 dev eth0
10.132.2.0/23 dev eth0 proto kernel scope link src 10.132.2.46

所以eth0@if4256是pod的主網絡接口。

讓我們獲取eth0設備的詳細信息。

從下面的輸出可以看出，pod網絡命名空間中的eth0設備是一個veth設備。

[root@ocp-412-ovn-worker-1 core]# ip netns exec $NS ip -d li sh dev eth0
link/ether 0a:58:0a:84:02:2e brd ff:ff:ff:ff:ff:ff link-netns 59e250f6–0491–4ff4-bb22-baa3bca249f6
veth addrgenmode eui64 numtxqueues 8 numrxqueues 8 gso_max_size 65536 gso_max_segs 65535 tso_max_size 524280 tso_max_segs 65535 gro_max_size 65536

眾所周知veth設備以對的形式工作；一端在init(或root)命名空間中，另一端在(pod)網絡命名空間中。

讓我們在init命名空間中找到pod對應的veth設備對。

[root@ocp-412-ovn-worker-1 core]# ip a | grep -A1 ^4256
4256: 8b7266486ea2861@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue master ovs-system state UP group default
link/ether de:fb:3e:87:0f:d6 brd ff:ff:ff:ff:ff:ff link-netns c16c7a01–1bc5–474a-9eb6–15474b5fbf04

所以，8b7266486ea2861@if2是init命名空間中的podveth設備端點。這個veth對連接了init和pod網絡命名空間。

讓我們找出veth設備端點的詳細信息。

[root@ocp-412-ovn-worker-1 core]# ip -d li sh dev 8b7266486ea2861
4256: 8b7266486ea2861@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue master ovs-system state UP mode DEFAULT group default
link/ether de:fb:3e:87:0f:d6 brd ff:ff:ff:ff:ff:ff link-netns c16c7a01–1bc5–474a-9eb6–15474b5fbf04 promiscuity 1 minmtu 68 maxmtu 65535
veth
openvswitch_slave addrgenmode eui64 numtxqueues 4 numrxqueues 4 gso_max_size 65536 gso_max_segs 65535

所以8b7266486ea2861@if2是一個OVS實體。轉儲OVS交換機詳細信息將提供哪個OVS橋擁有此端口的詳細信息。

如下輸出所示，橋br-int擁有這個端口。

注意，使用ovs-vsctl命令是之前ovs-ofctl dump-ports <bridge> <port>命令的另一種選擇。這是為了展示不同的命令可以幫助探索網絡拓撲結構。

[root@ocp-412-ovn-worker-1 core]# ovs-vsctl show


[snap]


Bridge br-int
        fail_mode: secure
        datapath_type: system


        [snip]


        Port "8b7266486ea2861"
            Interface "8b7266486ea2861"


[snap]

所以br-int擁有在init命名空間中具有podveth端點的端口。回想一下，它還持有ovn-k8s-mp0端口。

讓我們也獲取pod的vxlan詳細信息。

如下輸出所示，vxlan隧道的遠端點是IP192.168.10.201。這是pod虛擬機的IP。

[root@ocp-412-ovn-worker-1 core]# ip netns exec $NS ip -d li sh dev vxlan1
4257: vxlan1@if4257: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 
link/ether ca:40:81:86:fa:73 brd ff:ff:ff:ff:ff:ff link-netns 59e250f6–0491–4ff4-bb22-baa3bca249f6 promiscuity 0 minmtu 68 maxmtu 65535
vxlan id 555005 remote 192.168.10.201 srcport 0 0 dstport 4789 nolearning ttl auto ageing 300 udpcsum noudp6zerocsumtx noudp6zerocsumrx addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535

一個浮現的問題是數據包如何從eth0接口發送到vxlan1接口。

這是通過在網絡命名空間中設置Linux流量控制(TC)在eth0和vxlan1之間鏡像流量來實現的。這是從Kata容器的設計中已知的。然而，我認為在故障排除網絡問題時檢查TC配置是一種好的實踐。

下面的輸出顯示了我環境中pod網絡命名空間中設備配置的TC過濾器。

[root@ocp-412-ovn-worker-1 core]# ip netns exec $NS tc filter show dev eth0 root
filter parent ffff: protocol all pref 49152 u32 chain 0
filter parent ffff: protocol all pref 49152 u32 chain 0 fh 800: ht divisor 1
filter parent ffff: protocol all pref 49152 u32 chain 0 fh 800::800 order 2048 key ht 800 bkt 0 terminal flowid not_in_hw
  match 00000000/00000000 at 0
        action order 1: mirred (Egress Redirect to device vxlan1) stolen
        index 1 ref 1 bind 1


[root@ocp-412-ovn-worker-1 core]# ip netns exec $NS tc filter show dev vxlan1 root
filter parent ffff: protocol all pref 49152 u32 chain 0
filter parent ffff: protocol all pref 49152 u32 chain 0 fh 800: ht divisor 1
filter parent ffff: protocol all pref 49152 u32 chain 0 fh 800::800 order 2048 key ht 800 bkt 0 terminal flowid not_in_hw
  match 00000000/00000000 at 0
        action order 1: mirred (Egress Redirect to device eth0) stolen
        index 2 ref 1 bind 1

eth0的出口被重定向到了vxlan1，而vxlan1的出口被重定向到了eth0

有了所有這些細節，就可以為參考和進一步分析繪制工作節點網絡拓撲圖。拓撲結構如下圖所示。

圖片

現在，讓我們把重點轉到pod虛擬機上。

請注意，pod虛擬機的設計是使用一個名為podns的固定pod網絡命名空間。

以下輸出顯示了pod虛擬機的網絡配置:

ubuntu@podvm-nginx-priv-8b726648:/home/ubuntu# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:e1:58:67 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.201/24 brd 192.168.10.255 scope global dynamic ens2
valid_lft 2902sec preferred_lft 2902sec
inet6 fe80::5054:ff:fee1:5867/64 scope link
valid_lft forever preferred_lft forever


root@podvm-nginx-priv-8b726648:/home/ubuntu# ip r
default via 192.168.10.1 dev ens2 proto dhcp src 192.168.10.201 metric 100
192.168.10.0/24 dev ens2 proto kernel scope link src 192.168.10.201
192.168.10.1 dev ens2 proto dhcp scope link src 192.168.10.201 metric 100


root@podvm-nginx-priv-8b726648:/home/ubuntu# iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

以下輸出顯示了podns網絡命名空間內的網絡配置。

root@podvm-nginx-priv-8b726648:/home/ubuntu# ip netns exec podns ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host  
       valid_lft forever preferred_lft forever
3: vxlan0@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 7e:e5:f7:e6:f5:1a brd ff:ff:ff:ff:ff:ff link-netnsid 0 
    inet 10.132.2.46/23 brd 10.132.3.255 scope global vxlan0
       valid_lft forever preferred_lft forever
    inet6 fe80::7ce5:f7ff:fee6:f51a/64 scope link  
       valid_lft forever preferred_lft forever


root@podvm-nginx-priv-8b726648:/home/ubuntu# ip netns exec podns ip r
default via 10.132.2.1 dev vxlan0  
10.132.2.0/23 dev vxlan0 proto kernel scope link src 10.132.2.46


root@podvm-nginx-36590ccc:/home/ubuntu# ip netns exec podns ip -d li sh vxlan0 
3: vxlan0@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 7e:e5:f7:e6:f5:1a brd ff:ff:ff:ff:ff:ff link-netnsid 0 promiscuity 0 minmtu 68 maxmtu 65535
    vxlan id 555005 remote 192.168.10.163 srcport 0 0 dstport 4789 nolearning ttl auto ageing 300 udpcsum noudp6zerocsumtx noudp6zerocsumrx addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535


root@podvm-nginx-priv-8b726648:/home/ubuntu# ip netns exec podns iptables -S  
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

vxlan隧道設置看起來正常。它顯示了遠程端點IP 192.168.10.163，這是工作節點虛擬機的IP。

此外，pod虛擬機中沒有防火墻規則。

但是，你沒有看到像在工作節點上一樣的veth對。現在，浮現的一個問題是，沒有veth對，init和podns網絡命名空間之間如何進行通信。請注意，物理設備在init(root)命名空間中，vxlan設備在podns網絡命名空間中。

感謝Stefano Brivio指出了使這種情況發生的Linux內核提交。

commit f01ec1c017dead42092997a2b8684fcab4cbf126
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu Apr 24 10:02:49 2014 +0200
vxlan: add x-netns support
 
 This 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 -vv
tcpdump: 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 64
10: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 64
10: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 64
10: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-mp0

0a: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 down
ip netns exec podns ip link set dev vxlan0 address 0a:58:0a:84:02:2e
ip netns exec podns ip link set vxlan0 up

最終的網絡拓撲結構如下所示。

圖片

結論

我希望這篇文章對你有幫助。

以下是在我的故障排除練習中非常有用的參考資料列表:

https://learnk8s.io/kubernetes-network-packets
https://programmer.help/blogs/practice-vxlan-under-linux.html
https://www.man7.org/linux/man-pages/man7/ovn-architecture.7.html
https://developers.redhat.com/articles/2022/04/06/introduction-linux-bridging-commands-and-features#vlan_tunnel_mapping
https://www.tkng.io/cni/flannel/
https://access.redhat.com/documentation/en-us/openshift_container_platform/3.4/html/cluster_administration/admin-guide-sdn-troubleshooting#debugging-local-networking

責任編輯：武曉燕來源：云云眾生s

Kubernetes 集群網絡