Kubernetes ネットワークのトラブルシューティングの実践

Kata/リモートハイパーバイザー (ピアポッドとも呼ばれる) シナリオを開発しているときに、ワーカーノードで Kubernetes ポッド IP にアクセスできないという問題が発生しました。このブログでは、Kubernetes ネットワークのトラブルシューティングプロセスについて説明します。読者の皆様のお役に立てれば幸いです。

「実践的な Kubernetes ネットワークトラブルシューティングの旅」からの翻訳。

Kata リモート管理プログラム (ピアポッド) アプローチでは、AWS や Microsoft Azure などのインフラストラクチャ環境でネイティブインフラストラクチャ管理 API を使用して、任意のインフラストラクチャ環境で Kata VM を作成できます (たとえば、AWS で Kata VM を作成する場合は AWS API が使用され、Azure で Kata VM を作成する場合は Microsoft Azure API が使用されます)。 CNCF 機密コンテナプロジェクトの cloud-api-adaptor サブプロジェクトは、Kata リモート管理プログラムを実装します。

下の図に示すように、ピアポッドソリューションでは、ポッド (Kata) 仮想マシンは Kubernetes (K8s) ワーカーノードの外部で実行され、ポッド IP は VXLAN トンネルを介してワーカーノードからアクセスされます。トンネルを使用すると、CNI ネットワークに変更を加えなくても、ポッドネットワークが引き続き適切に機能することが保証されます。

写真

Kata コンテナを使用する場合、Kubernetes ポッドは仮想マシン内で実行されるため、ポッドを実行する仮想マシンを Kata VM またはポッド仮想マシンと呼びます。

質問

ポッド VM (IP: 192.168.10.201) にあるポッド IP 10.132.2.46 には、ワーカーノード VM (IP: 192.168.10.163) からアクセスできません。

私の環境内の VM の詳細は次のとおりです - ワーカー VM とポッド (Kata) VM。使用される Kubernetes CNI は OVN-Kubernetes です。

 +===========================+================+================+ | VM名称| IP地址| 备注| +===========================+================+================+ | ocp-412-ovn-worker-1 | 192.168.10.163 | 工作节点虚拟机| +---------------------------+----------------+----------------+ | podvm-nginx-priv-8b726648 | 192.168.10.201 | Pod虚拟机| +---------------------------+----------------+----------------+

最も簡単な解決策は、ネットワークの専門家に問題の解決を依頼することです。しかし、私の場合、他の緊急の問題があったため、専門家は解決に直接参加することができませんでした。さらに、ピアポッドネットワークトポロジは比較的新しいものであり、Kubernetes CNI、Kata Networking、VXLAN トンネルなどの複数のネットワークスタックが関係していたため、根本原因を特定するのが難しく、時間がかかりました。

したがって、私はこの状況を Kubernetes ネットワークスキルを向上させる機会だと捉えました。 Linux ネットワークコアの専門家の指導の下、私は独自にデバッグを始めました。

次の章では、デバッグと問題の根本原因の発見に対する私のアプローチについて説明します。このプロセスが Kubernetes ネットワークの問題のトラブルシューティングに役立つことを願っています。

トラブルシューティング - フェーズ 1

大まかに言うと、私が取ったアプローチには 2 つのステップが含まれます。

ネットワークトポロジの理解
トポロジから問題のある部分を特定する

ワーカーノード VM から IP:10.132.2.46 に ping を実行し、ネットワークスタック内のトラフィックをトレースしてみましょう。

 [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

したがって、ポッド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 の 2 つのブリッジしかありません。

 [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です。

それでは、ポッドのネットワーク構成の詳細を取得しましょう。

ポッドネットワークの詳細を決定するには、ポッドネットワークの名前空間を知っている必要があります。次のコマンドは、IP によってポッドネットワーク名前空間を検索します。

 [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

ポッドのネットワーク名前空間がわかれば、以下に示すようにポッドのネットワーク構成の詳細を見つけることができます。

 [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 はポッドのプライマリネットワークインターフェイスです。

eth0 デバイスの詳細を取得しましょう。

以下の出力からわかるように、ポッドネットワーク名前空間内の 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 デバイスはペアで動作することはよく知られています。 1 つは init (または root) 名前空間にあり、もう 1 つは (pod) ネットワーク名前空間にあります。

init 名前空間内のポッドに対応する 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 ポートも保持されていることに注意してください。

ポッドの vxlan の詳細も取得しましょう。

次の出力に示すように、vxlan トンネルのリモートエンドポイントは IP 192.168.10.201 です。これはポッド VM の 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

1 つの疑問は、eth0 インターフェイスから vxlan1 インターフェイスにパケットがどのように送信されるかということです。

これは、ネットワーク名前空間に Linux Traffic Control (TC) を設定し、eth0 と vxlan1 間のトラフィックをミラーリングすることによって実現されます。これは、Kata コンテナのデザインからわかります。ただし、ネットワークの問題をトラブルシューティングするときは、TC 構成を確認することをお勧めします。

以下の出力は、私の環境のポッドネットワーク名前空間内のデバイス用に構成された 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にリダイレクトされます。

これらすべての詳細を使用して、参照およびさらなる分析のためにワーカーノードネットワークトポロジ図を描くことができます。トポロジーを下図に示します。

写真

ここで、ポッド仮想マシンに焦点を当ててみましょう。

ポッド VM は、podns と呼ばれる固定のポッドネットワーク名前空間を使用するように設計されていることに注意してください。

次の出力は、ポッド VM のネットワーク構成を示しています。

 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 トンネルの設定は問題ないようです。ワーカーノード VM の IP であるリモートエンドポイント IP 192.168.10.163 が表示されます。

さらに、ポッド VM にはファイアウォールルールがありません。

ただし、ワーカーノードと同じ veth ペアは表示されません。ここで、init と podns のネットワーク名前空間が veth ペアなしでどのように通信できるかという疑問が生じます。物理デバイスは init(root) 名前空間にあり、vxlan デバイスは podns ネットワーク名前空間にあることに注意してください。

これを実現する Linux カーネルコミットを指摘してくれた Stefano Brivio に感謝します。

 commit f01ec1c017dead42092997a2b8684fcab4cbf126 Author: Nicolas Dichtel <[email protected]> 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 のトピックでも説明されています。

これらの詳細により、次の図に示すように、ポッド VM ネットワークトポロジの概要がわかりやすくなります。

写真

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]

さて、状況をまとめてみましょう。

この演習が終了すると、ワーカーノードとポッド VM のネットワークトポロジを十分に理解でき、トンネルの設定も正常に行われていることがわかります。また、ICMP パケットがポッド VM によって受信され、パケットをブロックするソフトウェアファイアウォールが存在しないこともわかります。では次は何でしょうか?

次に何をすべきかを知るには、読み進めてください :-)

トラブルシューティング - フェーズ 2

動作中の (通常の Kata) セットアップからの tcpdump キャプチャを分析するために、Wireshark を使用しました。 Wireshark のグラフィカルインターフェイスを使用すると、tcpdump 経由でキャプチャされたネットワークトレースを簡単に理解できます。

トレースでは ARP 要求と応答は観察されません。ただし、ワーカーノード上の ARP テーブルには、ポッド VM 上の podns 名前空間の vxlan0 デバイスの MAC ではなく、ポッドネットワーク名前空間 (ワーカーノード上) の eth0 デバイスの MAC が入力されます。

 ? (10.132.2.46) at 0a:58:0a:84:02:2e [ether] on ovn-k8s-mp0

0a:58:0a:84:02:2e は、ワーカーノード上のポッドネットワーク名前空間の eth0 インターフェイスの MAC であり、7e:e5:f7:e6:f5:1a は、ポッド VM 上の podns 名前空間の vxlan0 インターフェイスの MAC です。

これが問題の原因でした。ポッド IP はワーカーノードからアクセスできませんでした。 ARP エントリは、ポッド VM 上の podns 名前空間内の vxlan0 デバイスの MAC (つまり、7e:e5:f7:e6:f5:1a) を指す必要があります。

後から考えてみると、最初に ARP テーブルエントリを確認するべきでした。次回同様の問題に遭遇したときは、必ず同じことをします ;)

解決

Stefano Brivio によるちょっとしたトリックでこの問題は解決します。ワーカーノード上のポッドの eth0 インターフェイスと同じ MAC アドレスをポッド VM の vxlan0 インターフェイスで使用すると、接続の問題が解決しました。

 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

最終的なネットワークトポロジを以下に示します。

写真

結論は

Kubernetes クラスター内のネットワークの問題をデバッグするのは簡単ではありません。ただし、明確な方法論、専門家の支援、公開されている情報があれば、根本的な原因を見つけて問題を解決することは可能です。楽しみながら知識を身につけましょう。

この記事がお役に立てば幸いです。

以下は、トラブルシューティングの演習中に非常に役立った参考資料のリストです。

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

<<: 10分で自分のイメージを構築する方法を学ぶ

>>: クラウドの近代化は総合的なアプローチになる