☰

Das Ubuntu 20.04-Routing für nur eine IP (im selben Subnetz) endet mit „dev lo“ statt mit „dev eth0“, der Kubernetes-Workerknoten kann keine Verbindung zum Masterknoten herstellen

tag-icon • tag-icon ubuntu routing linux-networking kubernetes
Das Ubuntu 20.04-Routing für nur eine IP (im selben Subnetz) endet mit „dev lo“ statt mit „dev eth0“, der Kubernetes-Workerknoten kann keine Verbindung zum Masterknoten herstellen

Ich bin auf ein (wie es mir jetzt scheint) Routing-Problem gestoßen. Ich kann von meinem Masterknoten (Server) nicht mehr auf einen meiner Worker-Knoten (Server) zugreifen. Soweit ich weiß, hat das nichts mit Kubernetes zu tun, sondern ist ein reines Linux-Netzwerkproblem. Da das Problem nur eine IP betrifft, habe ich iptables behoben, TRACE aktiviert und festgestellt, dass das Paket tatsächlich über den Master (eth0) ankommt, zu iptables gelangt (Durchläufe: raw > mangle > nat), aber wenn es von nat zum Filter weitergeleitet werden muss, verschwindet es einfach. So wie ich es verstehe, ist dies der Punkt, an dem der Kernel die Routing-Entscheidung treffen muss. Habe das Routing überprüft und festgestellt, dass es nur für diese eine IP nicht funktioniert (alle anderen aus demselben IP-Segment funktionieren einwandfrei) !? Da ich bei einem Cloud-Anbieter bin und keine Netzwerkprobleme beheben kann, habe ich versucht, das Betriebssystem (dasselbe Ubuntu 20.04) des Masterknotens (Servers) neu zu installieren. Habe herausgefunden, dass das Problem bei der Neuinstallation des Betriebssystems nicht auftrat. Das Konfigurationsproblem muss daher an meinem Linux-Masterserver liegen (ich habe das Server-Image vom Snapshot zurückgesetzt).

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

Alle Hinweise darauf, was dort vor sich geht, sind mehr als willkommen!!!

Danke

BEARBEITEN: Nachdem das Problem gelöst wurde, ist es erwähnenswert, dass dieses Verhalten mit Kubernetes 1.21.2-00 und Flannel als CNI auftrat. Ich habe das Upgrade vor einigen Wochen durchgeführt und dies war der erste Neustart eines Worker-Knotens nach dem Upgrade.

Antwort1

GELÖST!

Der Bösewicht war tatsächlich Kubernetes – er hat eine LOKALE Route auf dem Masterknoten eingerichtet, die ohne den funktionalen Netzwerkdienst von Kubernetes (in meinem Fall Flannel) nicht funktionieren kann. Daher konnte der Workerknoten beim Neustart nicht mehr auf den API-Dienst des Masterknotens (6443/tcp) zugreifen und sich der API nicht präsentieren – dieser geschlossene magische Kreis, in dem der Workerknoten erfolglos in einer Schleife steckte.

Ich habe heute etwas über „lokale“ Routen gelernt, die vom Kernel verwaltet werden (alle aktuellen Routing-Tabellen finden Sie hier: /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

Route löschen

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

und jetzt funktioniert es

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

verwandte Informationen