Ubuntu 20.04 のルーティングが 1 つの IP (同じサブネット内) のみの場合、「dev eth0」ではなく「dev lo」で終了し、Kubernetes ワーカー ノードがマスター ノードに接続できない

Ubuntu 20.04 のルーティングが 1 つの IP (同じサブネット内) のみの場合、「dev eth0」ではなく「dev lo」で終了し、Kubernetes ワーカー ノードがマスター ノードに接続できない

ルーティングの問題にぶつかりました(今ではそう思えます)。マスターノード(サーバー)からワーカーノード(サーバー)の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

関連情報