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

Столкнулся (как мне теперь кажется) с маршрутизацией. Я больше не могу получить доступ к одному из своих рабочих узлов (серверу) с моего главного узла (сервера). Насколько я знаю, это не имеет ничего общего с Kubernetes, это приводит к чистой сетевой проблеме Linux. Поскольку проблема только с одним IP-адресом, я устранял неполадки iptables, включил TRACE и понял, что пакет на самом деле проходит через master (eth0), попадает в iptables (проходит: raw > mangle > nat), но когда он должен маршрутизироваться из nat в фильтр, он просто исчезает. Насколько я понимаю, это точка, в которой ядро ​​​​должно принять решение о маршрутизации.Проверил маршрутизацию и обнаружил, что она не работает только для одного IP-адреса (все остальные из того же IP-сегмента работают нормально)!? Поскольку я работаю с облачным провайдером и не могу устранить неполадки в сети, я попытался переустановить ОС (та же Ubuntu 20.04) главного узла (сервера). Выяснил, что при переустановке новой ОС проблема отсутствовала, поэтому проблема с конфигурацией должна быть на моем главном сервере Linux (я вернул образ сервера обратно из моментального снимка).

root@vmi57XXXX:~# маршрут  
Таблица IP-маршрутизации ядра  
Шлюз назначения Флаги Генмаски Метрика Ссылка Использование Iface  
по умолчанию 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 УГ 0 0 0 фланель.1  
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 докер0  
root@vmi57XXXX:~# IP-маршрут получить xx.xx.xx.96  
локальный xx.xx.xx.96 dev lo src xx.xx.xx.96 uid 0   
    кеш <локальный>   
root@vmi57XXXX:~# IP-маршрут получить xx.xx.xx.95  
xx.xx.xx.95 через xx.xx.xx.1 dev eth0 src xx.xx.xx.95 uid 0   
    тайник  
root@vmi57XXXX:~# IP-маршрут получить xx.xx.xx.97  
xx.xx.xx.97 через xx.xx.xx.1 dev eth0 src xx.xx.xx.97 uid 0   
    тайник   
  
root@vmi57XXXX:~# arp -v  
Адрес HWtype HWaddress Флаги Маска Iface  
10.244.0.60 эфир 8a:94:de:43:b6:0f C cni0  
10.244.0.63 эфир 1e:76:6a:60:27:f3 C cni0  
10.244.0.62 эфир 36:0b:19:5e:57:87 C cni0  
gw.provider.net эфир 00:c0:1d:c0:ff:ee C eth0  
10.244.0.64 эфир 82:03:61:c5:4d:fb C cni0  
10.244.0.50 (неполный) cni0  
10.244.1.0 эфир 52:3d:a5:f4:c2:2c CM фланель.1  
10.244.0.61 эфир 56:19:98:79:a1:3a C cni0  
Записей: 8 Пропущено: 0 Найдено: 8  

root@vmi57XXXX:~# ip netconf show dev eth0
inet eth0 переадресация вкл. rp_filter выкл. mc_forwarding выкл. proxy_neigh выкл. 
ignore_routes_with_linkdown выключен 
inet6 eth0 переадресация выключена mc_forwarding выключена proxy_neigh выключена 
ignore_routes_with_linkdown выключен 

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

Спасибо

РЕДАКТИРОВАТЬ: после решения проблемы стоит упомянуть, что такое поведение наблюдалось с Kubernetes 1.21.2-00 и фланелью как CNI. Я сделал обновление несколько недель назад, и это был первый перезапуск одного рабочего узла после обновления.