%20%E3%81%AE%E3%81%BF%E3%81%AE%E5%A0%B4%E5%90%88%E3%80%81%E3%80%8Cdev%20eth0%E3%80%8D%E3%81%A7%E3%81%AF%E3%81%AA%E3%81%8F%E3%80%8Cdev%20lo%E3%80%8D%E3%81%A7%E7%B5%82%E4%BA%86%E3%81%97%E3%80%81Kubernetes%20%E3%83%AF%E3%83%BC%E3%82%AB%E3%83%BC%20%E3%83%8E%E3%83%BC%E3%83%89%E3%81%8C%E3%83%9E%E3%82%B9%E3%82%BF%E3%83%BC%20%E3%83%8E%E3%83%BC%E3%83%89%E3%81%AB%E6%8E%A5%E7%B6%9A%E3%81%A7%E3%81%8D%E3%81%AA%E3%81%84.png)
ルーティングの問題にぶつかりました(今ではそう思えます)。マスターノード(サーバー)からワーカーノード(サーバー)の1つにアクセスできなくなりました。私の知る限り、これはKubernetesとは関係なく、純粋なLinuxネットワークの問題につながります。問題は1つのIPだけにあるため、iptablesのトラブルシューティングを行っていて、TRACEを有効にしたところ、パケットは実際にはマスター(eth0)を通過し、iptablesに到達しますが(パス:raw > mangle > nat)、natからフィルターにルーティングされる必要があるときに消えてしまうことに気付きました。私の理解では、それがカーネルがルーティングの決定を行う必要があるポイントです。ルーティングをチェックしたところ、その1つのIPだけで機能していないことがわかりました(同じIPセグメントの他のすべては正常に機能しています)!?私はクラウドプロバイダーを使用しており、ネットワークのトラブルシューティングができないため、マスターノード(サーバー)のOS(同じUbuntu 20.04)を再インストールしてみました。 OS を新規に再インストールすると、問題は発生しないことが判明したため、構成の問題はマスター Linux サーバー内にあるはずです (サーバー イメージをスナップショットから戻しました)。
root@vmi57XXXX:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default gw.provider.net 0.0.0.0 UG 0 0 0 eth0
10.244.0.0 0.0.0.0 255.255.255.0 U 0 0 0 cni0
10.244.1.0 10.244.1.0 255.255.255.0 UG 0 0 0 flannel.1
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
root@vmi57XXXX:~# ip route get xx.xx.xx.96
local xx.xx.xx.96 dev lo src xx.xx.xx.96 uid 0
cache <local>
root@vmi57XXXX:~# ip route get xx.xx.xx.95
xx.xx.xx.95 via xx.xx.xx.1 dev eth0 src xx.xx.xx.95 uid 0
cache
root@vmi57XXXX:~# ip route get xx.xx.xx.97
xx.xx.xx.97 via xx.xx.xx.1 dev eth0 src xx.xx.xx.97 uid 0
cache
root@vmi57XXXX:~# arp -v
Address HWtype HWaddress Flags Mask Iface
10.244.0.60 ether 8a:94:de:43:b6:0f C cni0
10.244.0.63 ether 1e:76:6a:60:27:f3 C cni0
10.244.0.62 ether 36:0b:19:5e:57:87 C cni0
gw.provider.net ether 00:c0:1d:c0:ff:ee C eth0
10.244.0.64 ether 82:03:61:c5:4d:fb C cni0
10.244.0.50 (incomplete) cni0
10.244.1.0 ether 52:3d:a5:f4:c2:2c CM flannel.1
10.244.0.61 ether 56:19:98:79:a1:3a C cni0
Entries: 8 Skipped: 0 Found: 8
root@vmi57XXXX:~# ip netconf show dev eth0
inet eth0 forwarding on rp_filter off mc_forwarding off proxy_neigh off
ignore_routes_with_linkdown off
inet6 eth0 forwarding off mc_forwarding off proxy_neigh off
ignore_routes_with_linkdown off
そこで何が起こっているかについての手がかりがあれば、ぜひ教えてください!!!
ありがとう
編集: 問題を解決した後、この動作は Kubernetes 1.21.2-00 と CNI としての flannel で発生したことを言及する価値があります。数週間前にアップグレードを実行しましたが、これはアップグレード後の 1 つのワーカー ノードの最初の再起動でした。
答え1
解決しました!
悪者は実は Kubernetes でした。Kubernetes はマスター ノードにローカル ルートを設定しましたが、これは Kubernetes の機能ネットワーク サービス (私の場合は flannel) がなければ機能しません。そのため、ワーカー ノードが再起動されると、マスター ノードの API サービス (6443/tcp) にアクセスできなくなり、API に自分自身を公開できなくなりました。つまり、ワーカー ノードがうまくいかずにループする閉じた魔法の円です。
今日、カーネルによって管理される「ローカル」ルートについて学びました (現在のすべてのルーティング テーブルは、/etc/iproute2/rt_tables にあります)。
ip route ls table local
local xx.xx.xx.96 dev kube-ipvs0 proto kernel scope host src xx.xx.xx.96 <<< PROBLEMATIC
local xx.xx.xx.50 dev eth0 proto kernel scope host src xx.xx.xx.50 <<< i.e. OK
ルートを削除
ip route del table local local xx.xx.xx.96 dev kube-ipvs0 proto kernel scope host src xx.xx.xx.96
そして今、それは機能している
root@vmi57XXXX:~# ip route get xx.xx.xx.96
xx.xx.xx.96 via xx.xx.xx.1 dev eth0 src xx.xx.xx.50 uid 0
cache