☰

Ubuntu 20.04 僅一個 IP（在同一子網路中）的路由以「dev lo」而不是「dev eth0」結尾，kubernetes 工作節點無法連接到主節點

tag-icon • tag-icon ubuntu routing linux-networking kubernetes
Ubuntu 20.04 僅一個 IP（在同一子網路中）的路由以「dev lo」而不是「dev eth0」結尾，kubernetes 工作節點無法連接到主節點

我遇到了（現在看來）路由問題。我無法再從主節點（伺服器）存取我的工作節點（伺服器）之一。 AFAIK，它與 Kubernetes 無關，它會導致純粹的 Linux 網路問題。由於問題僅涉及一個IP，我對iptables 進行了故障排除，啟用了TRACE 並意識到資料包實際上跨越了master (eth0)，到達了iptables（透過：raw > mangle >nat），但是當它必須從nat 路由到過濾一下，它就消失了。據我了解，這是核心必須做出路由決策的點。檢查路由，發現它不適用於僅該一個IP（來自同一IP段的所有其他IP都工作正常）！由於我使用雲端供應商，無法排除網路故障，因此我嘗試重新安裝主節點（伺服器）的作業系統（相同的 Ubuntu 20.04）。發現重新安裝全新作業系統後，問題不存在，因此設定問題必須出現在我的主 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 和 flannel 作為 CNI 中都經歷過。我幾週前進行了升級，這是升級後第一次重新啟動一個工作節點。

答案1

解決了！

壞人實際上是 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

相關內容