Вопросы Теги

Ubuntu 20.04 маршрутизация только для одного IP (в той же подсети) заканчивается на "dev lo" вместо "dev eth0", рабочий узел kubernetes не может подключиться к главному узлу

, я столкнулся с (как мне теперь кажется) проблемой маршрутизации. Я больше не могу получить доступ к одному из моих рабочих узлов (серверу) с моего главного узла (сервера). AFAIK, это не имеет ничего общего с Kubernetes, это приводит к чистой сетевой проблеме Linux. Поскольку проблема связана только с одним IP, я проверял iptables, включил TRACE и понял, что пакет действительно приходит через master (eth0), попадает в iptables (проходит: raw > mangle >nat), но когда он должен пройти маршрутизацию от nat к фильтру, он просто исчезает. Как я понимаю, именно в этот момент ядро должно принять решение о маршрутизации. Проверил маршрутизацию и обнаружил, что она не работает только для этого одного 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
задан 2 September 2021 в 08:39
1 ответ

РЕШЕНО!

Плохим парнем на самом деле был Kubernetes — он установил маршрут L O C A L на главном узле, который не может работать без функциональной сетевой службы 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
1
ответ дан 2 September 2021 в 09:33

Теги

Похожие вопросы