☰

O roteamento do Ubuntu 20.04 para apenas um IP (na mesma sub-rede) termina em "dev lo" em vez de "dev eth0", o nó de trabalho do Kubernetes não pode se conectar ao nó mestre

tag-icon • tag-icon ubuntu routing linux-networking kubernetes
O roteamento do Ubuntu 20.04 para apenas um IP (na mesma sub-rede) termina em "dev lo" em vez de "dev eth0", o nó de trabalho do Kubernetes não pode se conectar ao nó mestre

Eu me deparei com (como agora me parece) um problema de roteamento. Não consigo mais acessar um dos meus nós de trabalho (servidor) do meu nó mestre (servidor). AFAIK, não tem nada a ver com Kubernetes, leva a um puro problema de rede Linux. Como o problema é com apenas um IP, eu estava solucionando problemas de iptables, habilitei o TRACE e percebi que o pacote na verdade vem através do master (eth0), chega ao iptables (passa: raw > mangle >nat), mas quando ele precisa ser roteado de nat para filtro, ele simplesmente desaparece. Pelo que entendi, esse é o ponto em que o kernel deve tomar a decisão de roteamento. Verifiquei o roteamento e descobri que não está funcionando apenas para aquele IP (todos os outros do mesmo segmento IP estão funcionando bem)!? Como estou com um provedor de nuvem e não consigo solucionar problemas de rede, tentei reinstalar o sistema operacional (mesmo Ubuntu 20.04) do nó mestre (servidor). Descobri que com a nova reinstalação do sistema operacional, o problema não estava presente, portanto, o problema de configuração deve estar dentro do meu servidor Linux mestre (reverti a imagem do servidor de volta ao instantâneo).

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

Qualquer pista sobre o que está acontecendo por lá é mais que bem vinda!!!

Obrigado

EDIT: Após resolver o problema vale ressaltar que esse comportamento ocorreu com Kubernetes 1.21.2-00 e flanela como CNI. Fiz a atualização há algumas semanas e esta foi a primeira reinicialização de um nó de trabalho após a atualização.

Responder1

RESOLVIDO!

o bandido era na verdade o Kubernetes - ele definiu uma rota LOCAL no nó mestre que não pode funcionar sem o serviço de rede funcional do Kubernetes (flanela - no meu caso). Portanto, quando o nó de trabalho foi reinicializado, ele não foi mais capaz de acessar o serviço API do nó mestre (6443/tcp) e não pôde se apresentar à API - aquele círculo mágico fechado no qual o nó waker fez um loop sem sorte.

Aprendi hoje sobre rotas "locais" mantidas pelo kernel (todas as tabelas de roteamento atuais podem ser encontradas aqui: /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

excluir rota

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

e agora 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

informação relacionada