kube-ovn ovn 原生 fip 基準(zhǔn)測試

fip

跨節(jié)點

  1. fip pod <--> fip pod
  2. fip pod <--> underlay pod

snat

跨節(jié)點

  1. vpc pod <--> fip pod
  2. vpc pod <--> underlay pod

目前在fip場景2測試中發(fā)現(xiàn),tcp帶寬最大有8.6G,所以可以判斷集群內(nèi)部fip的流量先經(jīng)過tunnel網(wǎng)卡過去,再經(jīng)過snat包轉(zhuǎn)換,實際上這個過程可以看做沒有經(jīng)過公網(wǎng)網(wǎng)橋(網(wǎng)卡千兆)。


[root@k8s-ctrl-1 ~]# k exec -it -n vpc1                   poc-pod-1 -- /bin/sh
sh-4.2# ping 10.5.49.12
PING 10.5.49.12 (10.5.49.12) 56(84) bytes of data.
64 bytes from 10.5.49.12: icmp_seq=1 ttl=63 time=3.49 ms
64 bytes from 10.5.49.12: icmp_seq=2 ttl=63 time=0.966 ms
64 bytes from 10.5.49.12: icmp_seq=3 ttl=63 time=0.287 ms
64 bytes from 10.5.49.12: icmp_seq=4 ttl=63 time=0.332 ms
64 bytes from 10.5.49.12: icmp_seq=5 ttl=63 time=0.235 ms
64 bytes from 10.5.49.12: icmp_seq=6 ttl=63 time=0.286 ms
64 bytes from 10.5.49.12: icmp_seq=7 ttl=63 time=0.329 ms
64 bytes from 10.5.49.12: icmp_seq=8 ttl=63 time=0.352 ms
64 bytes from 10.5.49.12: icmp_seq=9 ttl=63 time=0.319 ms
64 bytes from 10.5.49.12: icmp_seq=10 ttl=63 time=0.370 ms
64 bytes from 10.5.49.12: icmp_seq=11 ttl=63 time=0.287 ms
64 bytes from 10.5.49.12: icmp_seq=12 ttl=63 time=0.462 ms
64 bytes from 10.5.49.12: icmp_seq=13 ttl=63 time=0.377 ms
64 bytes from 10.5.49.12: icmp_seq=14 ttl=63 time=0.352 ms
64 bytes from 10.5.49.12: icmp_seq=15 ttl=63 time=0.307 ms

# 1. 可以看到包在pod出去后直接走tunnel網(wǎng)卡過去了,并沒有進(jìn)行snat轉(zhuǎn)換

[root@k8s-ctrl-2 ~]#  tcpdump -i any host 10.5.49.12 and icmp -netvv
dropped privs to tcpdump
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes




  P 00:00:00:1f:9f:79 ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 64, id 29270, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.9 > 10.5.49.12: ICMP echo request, id 189, seq 1, length 64
Out 00:00:00:8c:bb:46 ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 63, id 29270, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.9 > 10.5.49.12: ICMP echo request, id 189, seq 1, length 64
  P 00:00:00:55:2d:76 ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 63, id 37099, offset 0, flags [none], proto ICMP (1), length 84)
    10.5.49.12 > 192.168.0.9: ICMP echo reply, id 189, seq 1, length 64
Out 00:00:00:55:2d:76 ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 63, id 37099, offset 0, flags [none], proto ICMP (1), length 84)
    10.5.49.12 > 192.168.0.9: ICMP echo reply, id 189, seq 1, length 64
  P 00:00:00:1f:9f:79 ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 64, id 30144, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.9 > 10.5.49.12: ICMP echo request, id 189, seq 2, length 64
Out 00:00:00:8c:bb:46 ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 63, id 30144, offset 0, flags [DF], proto ICMP (1), length 84)


# 2. 可以看到包在pod直接走tunnel網(wǎng)卡過去到目標(biāo)node后,才進(jìn)行snat轉(zhuǎn)換

[root@k8s-ctrl-1 ~]# tcpdump -i any host 10.5.49.12 and icmp -netvv
dropped privs to tcpdump
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
  P 00:00:00:8c:bb:46 ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 63, id 17251, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.0.9 > 10.5.49.12: ICMP echo request, id 188, seq 37, length 64
Out 00:00:00:8c:bb:46 ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 63, id 17251, offset 0, flags [DF], proto ICMP (1), length 84)
    10.5.49.5 > 10.5.49.12: ICMP echo request, id 188, seq 37, length 64
  P 00:00:00:bc:d2:86 ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 64, id 60186, offset 0, flags [none], proto ICMP (1), length 84)
    10.5.49.12 > 10.5.49.5: ICMP echo reply, id 188, seq 37, length 64

c0c0b004f435b5f720f25ce42226ee0.png
最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容