☰

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 工作节点无法连接到主节点

我遇到了（现在在我看来）路由问题。我无法再从主节点（服务器）访问我的一个工作节点（服务器）。据我所知，这与 Kubernetes 无关，它导致纯 Linux 网络问题。由于问题只出在一个 IP 上，我正在对 iptables 进行故障排除，启用了 TRACE 并意识到数据包实际上经过了主节点（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

相关内容