在開(kāi)發(fā)Kata/remote-hypervisor(也稱(chēng)為peer-pods)方案時(shí)，我遇到了一個(gè)問(wèn)題，即Kube.NETes pod IP在工作節(jié)點(diǎn)上無(wú)法訪問(wèn)。在本博客中，我將描述Kubernetes網(wǎng)絡(luò)故障排查過(guò)程，希望對(duì)讀者有幫助。
譯自A Hands-on Kubernetes Network Troubleshooting Journey。
Kata遠(yuǎn)程管理程序(peer-pods)方案通過(guò)在AWS或Microsoft Azure等基礎(chǔ)設(shè)施環(huán)境中使用本機(jī)基礎(chǔ)設(shè)施管理API(如在AWS上創(chuàng)建Kata VM時(shí)使用AWS API，在Azure上創(chuàng)建時(shí)使用Microsoft Azure API)，實(shí)現(xiàn)在任何基礎(chǔ)設(shè)施環(huán)境中創(chuàng)建Kata VM。CNCF保密容器項(xiàng)目的cloud-api-adaptor子項(xiàng)目實(shí)現(xiàn)了Kata遠(yuǎn)程管理程序。
如下圖所示，在peer-pods方案中，pod(Kata)虛擬機(jī)在Kubernetes(K8s)工作節(jié)點(diǎn)外部運(yùn)行，通過(guò)VXLAN隧道從工作節(jié)點(diǎn)訪問(wèn)pod IP。使用隧道可以確保pod聯(lián)網(wǎng)繼續(xù)正常工作，無(wú)需對(duì)CNI網(wǎng)絡(luò)做任何改變。
當(dāng)使用Kata容器時(shí)，Kubernetes pod在虛擬機(jī)內(nèi)運(yùn)行，因此我們將運(yùn)行pod的虛擬機(jī)稱(chēng)為Kata VM或pod虛擬機(jī)。
問(wèn)題
pod IP10.132.2.46，它位于pod虛擬機(jī)上(IP:192.168.10.201)，從工作節(jié)點(diǎn)虛擬機(jī)(IP:192.168.10.163)無(wú)法訪問(wèn)。
以下是我環(huán)境中的虛擬機(jī)詳細(xì)信息 —— 工作節(jié)點(diǎn)虛擬機(jī)和pod(Kata)虛擬機(jī)。使用的Kubernetes CNI是OVN-Kubernetes。
+===========================+================+================+
| VM名稱(chēng) | IP地址 | 備注 |
+===========================+================+================+
| ocp-412-ovn-worker-1 | 192.168.10.163 | 工作節(jié)點(diǎn)虛擬機(jī) |
+---------------------------+----------------+----------------+
| podvm-Nginx-priv-8b726648 | 192.168.10.201 | Pod虛擬機(jī) |
+---------------------------+----------------+----------------+
最簡(jiǎn)單的解決方案就是請(qǐng)網(wǎng)絡(luò)專(zhuān)家來(lái)解決這個(gè)問(wèn)題。然而，在我的情況下，由于其他緊迫問(wèn)題，專(zhuān)家無(wú)法直接參與解決。此外，peer-pods網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)還比較新，涉及多個(gè)網(wǎng)絡(luò)棧 —— Kubernetes CNI、Kata網(wǎng)絡(luò)和VXLAN隧道，使得根本原因難以查明且非常耗時(shí)。
因此，我將這種情況視為提高我的Kubernetes網(wǎng)絡(luò)技能的機(jī)會(huì)。在一些linux網(wǎng)絡(luò)核心專(zhuān)家的指導(dǎo)下，我開(kāi)始自行調(diào)試。
在后續(xù)章節(jié)中，我將通過(guò)我的方法帶您逐步了解調(diào)試過(guò)程和找到問(wèn)題根本原因。我希望這個(gè)過(guò)程能對(duì)Kubernetes網(wǎng)絡(luò)問(wèn)題故障排除有所幫助。
故障排查 - 第一階段
在高層面上，我采取的方法包含以下兩個(gè)步驟:
- 了解網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)
- 從拓?fù)浣Y(jié)構(gòu)中識(shí)別有問(wèn)題的部分
讓我們從工作節(jié)點(diǎn)虛擬機(jī)ping IP:10.132.2.46，并跟蹤網(wǎng)絡(luò)棧中的流量:
[root@ocp-412-worker-1 core]# ping 10.132.2.46
Linux會(huì)參考路由表來(lái)確定發(fā)送數(shù)據(jù)包的目的地。
[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的路由是通過(guò)設(shè)備ovn-k8s-mp0
讓我們獲取工作節(jié)點(diǎn)網(wǎng)絡(luò)詳細(xì)信息，并檢索有關(guān)ovn-k8s-mp0設(shè)備的信息。
[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接口的設(shè)備詳細(xì)信息。
如下輸出所示,這個(gè)接口是一個(gè)OVS實(shí)體。
[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是一個(gè)OVS橋嗎？
從下面的命令輸出可以清楚看到，ovn-k8s-mp0不是一個(gè)OVS橋。工作節(jié)點(diǎn)上存在的只有兩個(gè)橋:br-ex和br-int
[root@ocp-412-ovn-worker-1 core]# ovs-vsctl list-br
br-ex
br-int
所以ovn-k8s-mp0是一個(gè)OVS端口。我們需要找出擁有這個(gè)端口的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是一個(gè)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
總結(jié)一下，ovn-k8s-mp0是一個(gè)br-int** OVS橋上的端口。它也持有橋的IP，即**10.132.2.2/23
現(xiàn)在，讓我們獲取pod的網(wǎng)絡(luò)配置詳細(xì)信息。
必須知道pod網(wǎng)絡(luò)命名空間才能確定pod網(wǎng)絡(luò)詳細(xì)信息。下面的命令通過(guò)IP找到pod網(wǎng)絡(luò)命名空間。
[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網(wǎng)絡(luò)命名空間，就可以找到pod的網(wǎng)絡(luò)配置詳細(xì)信息，如下所示。
[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的主網(wǎng)絡(luò)接口。
讓我們獲取eth0設(shè)備的詳細(xì)信息。
從下面的輸出可以看出，pod網(wǎng)絡(luò)命名空間中的eth0設(shè)備是一個(gè)veth設(shè)備。
[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設(shè)備以對(duì)的形式工作；一端在init(或root)命名空間中，另一端在(pod)網(wǎng)絡(luò)命名空間中。
讓我們?cè)趇nit命名空間中找到pod對(duì)應(yīng)的veth設(shè)備對(duì)。
[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設(shè)備端點(diǎn)。這個(gè)veth對(duì)連接了init和pod網(wǎng)絡(luò)命名空間。
讓我們找出veth設(shè)備端點(diǎn)的詳細(xì)信息。
[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是一個(gè)OVS實(shí)體。轉(zhuǎn)儲(chǔ)OVS交換機(jī)詳細(xì)信息將提供哪個(gè)OVS橋擁有此端口的詳細(xì)信息。
如下輸出所示，橋br-int擁有這個(gè)端口。
注意，使用ovs-vsctl命令是之前ovs-ofctl dump-ports <bridge> <port>命令的另一種選擇。這是為了展示不同的命令可以幫助探索網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)。
[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端點(diǎn)的端口。回想一下，它還持有ovn-k8s-mp0端口。
讓我們也獲取pod的vxlan詳細(xì)信息。
如下輸出所示，vxlan隧道的遠(yuǎn)端點(diǎn)是IP192.168.10.201。這是pod虛擬機(jī)的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
一個(gè)浮現(xiàn)的問(wèn)題是數(shù)據(jù)包如何從eth0接口發(fā)送到vxlan1接口。
這是通過(guò)在網(wǎng)絡(luò)命名空間中設(shè)置Linux流量控制(TC)在eth0和vxlan1之間鏡像流量來(lái)實(shí)現(xiàn)的。這是從Kata容器的設(shè)計(jì)中已知的。然而，我認(rèn)為在故障排除網(wǎng)絡(luò)問(wèn)題時(shí)檢查T(mén)C配置是一種好的實(shí)踐。
下面的輸出顯示了我環(huán)境中pod網(wǎng)絡(luò)命名空間中設(shè)備配置的TC過(guò)濾器。
[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
有了所有這些細(xì)節(jié)，就可以為參考和進(jìn)一步分析繪制工作節(jié)點(diǎn)網(wǎng)絡(luò)拓?fù)鋱D。拓?fù)浣Y(jié)構(gòu)如下圖所示。
現(xiàn)在，讓我們把重點(diǎn)轉(zhuǎn)到pod虛擬機(jī)上。
請(qǐng)注意，pod虛擬機(jī)的設(shè)計(jì)是使用一個(gè)名為poDNS的固定pod網(wǎng)絡(luò)命名空間。
以下輸出顯示了pod虛擬機(jī)的網(wǎng)絡(luò)配置:
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網(wǎng)絡(luò)命名空間內(nèi)的網(wǎng)絡(luò)配置。
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隧道設(shè)置看起來(lái)正常。它顯示了遠(yuǎn)程端點(diǎn)IP 192.168.10.163，這是工作節(jié)點(diǎn)虛擬機(jī)的IP。
此外，pod虛擬機(jī)中沒(méi)有防火墻規(guī)則。
但是，你沒(méi)有看到像在工作節(jié)點(diǎn)上一樣的veth對(duì)。現(xiàn)在，浮現(xiàn)的一個(gè)問(wèn)題是，沒(méi)有veth對(duì)，init和podns網(wǎng)絡(luò)命名空間之間如何進(jìn)行通信。請(qǐng)注意，物理設(shè)備在init(root)命名空間中，vxlan設(shè)備在podns網(wǎng)絡(luò)命名空間中。
感謝Stefano Brivio指出了使這種情況發(fā)生的Linux內(nèi)核提交。
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
這也有一個(gè)StackOverflow主題對(duì)此進(jìn)行了解釋。
這些細(xì)節(jié)為我們提供了對(duì)pod虛擬機(jī)網(wǎng)絡(luò)拓?fù)涞牧己酶攀觯缦聢D所示。
讓我們?cè)趘xlan0接口上運(yùn)行tcpdump，看ICMP請(qǐng)求是否從工作節(jié)點(diǎn)接收。
如下輸出所示，ICMP請(qǐng)求已接收，但沒(méi)有響應(yīng)。
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]
現(xiàn)在，讓我們總結(jié)一下情況。
通過(guò)這個(gè)練習(xí)，你對(duì)工作節(jié)點(diǎn)和pod虛擬機(jī)的網(wǎng)絡(luò)拓?fù)溆辛撕芎玫睦斫猓淼赖脑O(shè)置看起來(lái)也沒(méi)有問(wèn)題。你也看到ICMP數(shù)據(jù)包被pod虛擬機(jī)接收，沒(méi)有軟件防火墻阻止數(shù)據(jù)包。那么下一步該做什么?
繼續(xù)閱讀以了解下一步該做什么:-)
故障排查 - 第二階段
我使用wireshark分析了來(lái)自工作正常(常規(guī)Kata)設(shè)置的tcpdump捕獲。Wireshark圖形界面可以方便地理解通過(guò)tcpdump捕獲的網(wǎng)絡(luò)跟蹤。
在跟蹤中沒(méi)有觀察到ARP請(qǐng)求和響應(yīng)。但是，工作節(jié)點(diǎn)上的ARP表被填充，ARP表使用pod網(wǎng)絡(luò)命名空間中的eth0設(shè)備的mac(在工作節(jié)點(diǎn)上)，而不是pod虛擬機(jī)上的podns命名空間中的vxlan0設(shè)備的MAC。
? (10.132.2.46) at 0a:58:0a:84:02:2e [ether] on ovn-k8s-mp0
0a:58:0a:84:02:2e是工作節(jié)點(diǎn)上pod網(wǎng)絡(luò)命名空間中eth0接口的MAC，而7e:e5:f7:e6:f5:1a是pod虛擬機(jī)上podns命名空間中的vxlan0接口的MAC。
這是問(wèn)題的原因 - 從工作節(jié)點(diǎn)無(wú)法訪問(wèn)pod IP。ARP條目應(yīng)指向pod虛擬機(jī)上podns命名空間中的vxlan0設(shè)備的MAC(即7e:e5:f7:e6:f5:1a)。
事后看來(lái)，我本該首先查看ARP表?xiàng)l目。下次遇到類(lèi)似問(wèn)題我一定會(huì)這么做;)
解決方案
Stefano Brivio的一個(gè)小技巧解決了這個(gè)問(wèn)題。在pod虛擬機(jī)的vxlan0接口上使用與工作節(jié)點(diǎn)上pod的eth0接口相同的MAC地址可以解決連接問(wèn)題。
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
最終的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)如下所示。
圖片
結(jié)論
調(diào)試Kubernetes集群中的網(wǎng)絡(luò)問(wèn)題并非易事。然而，通過(guò)明確的方法、專(zhuān)家的幫助和公開(kāi)可用的資料，找到根本原因和修復(fù)問(wèn)題是可能的。在這個(gè)過(guò)程中獲得樂(lè)趣并掌握知識(shí)。
我希望這篇文章對(duì)你有幫助。
以下是在我的故障排除練習(xí)中非常有用的參考資料列表:
- 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
