☰

Маршрутизация 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 в filter, он просто исчезает. Насколько я понимаю, это тот момент, когда ядро ​​должно принять решение о маршрутизации. Проверил маршрутизацию и обнаружил, что она не работает только для этого одного 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

Любые подсказки о том, что там происходит, будут более чем приветствоваться!!!

Спасибо

EDIT: После решения проблемы стоит отметить, что такое поведение наблюдалось с 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

Связанный контент