☰

동일한 서브넷에 있는 하나의 IP에 대한 Ubuntu 20.04 라우팅은 "dev eth0" 대신 "dev lo"로 끝나고 kubernetes 작업자 노드는 마스터 노드에 연결할 수 없습니다.

tag-icon • tag-icon ubuntu routing linux-networking kubernetes
동일한 서브넷에 있는 하나의 IP에 대한 Ubuntu 20.04 라우팅은 "dev eth0" 대신 "dev lo"로 끝나고 kubernetes 작업자 노드는 마스터 노드에 연결할 수 없습니다.

(지금 생각해보면) 라우팅 문제에 부딪혔습니다. 더 이상 내 마스터 노드(서버)에서 내 작업자 노드(서버) 중 하나에 액세스할 수 없습니다. AFAIK는 Kubernetes와 관련이 없으며 순수한 Linux 네트워킹 문제로 이어집니다. 문제는 하나의 IP에서만 발생하므로 iptables 문제를 해결하고 TRACE를 활성화했으며 패킷이 실제로 마스터(eth0)를 거쳐 iptables에 도착하지만(pass: raw > mangle > nat) nat에서 다음으로 라우팅되어야 한다는 것을 깨달았습니다. 필터링하면 그냥 사라집니다. 내가 이해하는 바로는 커널이 라우팅 결정을 내려야 하는 지점입니다. 라우팅을 확인한 결과 해당 IP에서만 작동하지 않는 것으로 나타났습니다(동일한 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로 경험했다는 점을 언급할 가치가 있습니다. 몇 주 전에 업그레이드를 수행했는데 업그레이드 후 작업자 노드 하나가 처음으로 다시 시작되었습니다.

답변1

해결되었습니다!

악당은 실제로 Kubernetes였습니다. Kubernetes의 기능적 네트워킹 서비스(내 경우에는 플란넬) 없이는 작동할 수 없는 마스터 노드에 로컬 경로를 설정했습니다. 따라서 작업자 노드가 재부팅되면 더 이상 마스터 노드의 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

관련 정보