☰

El enrutamiento de Ubuntu 20.04 para una sola IP (en la misma subred) termina en "dev lo" en lugar de "dev eth0", el nodo trabajador de Kubernetes no puede conectarse al nodo maestro

tag-icon • tag-icon ubuntu routing linux-networking kubernetes
El enrutamiento de Ubuntu 20.04 para una sola IP (en la misma subred) termina en "dev lo" en lugar de "dev eth0", el nodo trabajador de Kubernetes no puede conectarse al nodo maestro

Me topé con (como me parece ahora) un problema de enrutamiento. Ya no puedo acceder a uno de mis nodos trabajadores (servidor) desde mi nodo maestro (servidor). AFAIK, no tiene nada que ver con Kubernetes, conduce a un problema de red puro de Linux. Como el problema es con una sola IP, estaba solucionando problemas de iptables, habilité TRACE y me di cuenta de que el paquete en realidad llega a través del maestro (eth0), llega a iptables (pasa: raw > mangle >nat) pero cuando tiene que ser enrutado de nat a filtro, simplemente desaparece. Según tengo entendido, ese es el punto en el que el kernel tiene que tomar la decisión de enrutamiento. ¿Revisé el enrutamiento y descubrí que no funciona solo para esa IP (todas las demás del mismo segmento de IP funcionan bien)? Como trabajo con un proveedor de nube y no puedo solucionar problemas de red, intenté reinstalar el sistema operativo (el mismo Ubuntu 20.04) del nodo maestro (servidor). Descubrí que con la reinstalación del sistema operativo nuevo, el problema no estaba presente, por lo tanto, el problema de configuración debe estar dentro de mi servidor Linux maestro (revertí la imagen del servidor desde la instantánea).

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

¡¡¡Cualquier pista sobre lo que está pasando allí es más que bienvenida!!!

Gracias

EDITAR: Después de resolver el problema, vale la pena mencionar que este comportamiento se experimentó con Kubernetes 1.21.2-00 y franela como CNI. Hice la actualización hace unas semanas y este fue el primer reinicio de un nodo trabajador después de la actualización.

Respuesta1

¡SOLUCIONADO!

El malo era en realidad Kubernetes: estableció una ruta LOCAL en el nodo maestro que no puede funcionar sin el servicio de red funcional de Kubernetes (franela, en mi caso). Por lo tanto, cuando el nodo trabajador se reinició, ya no pudo acceder al servicio API del nodo maestro (6443/tcp) y no pudo presentarse a la API, ese círculo mágico cerrado en el que el nodo trabajador giró sin suerte.

Hoy aprendí sobre las rutas "locales" mantenidas por el kernel (todas las tablas de enrutamiento actuales se pueden encontrar aquí: /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

eliminar ruta

ip route del table local local xx.xx.xx.96 dev kube-ipvs0 proto kernel scope host src xx.xx.xx.96

y ahora funciona

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

información relacionada