Kubernetes Networking 101 für SRE: CNI auf OSI-Layer mappen

Kubernetes Networking 101 für SRE: CNI auf OSI-Layer mappen ist ein sehr pragmatischer Ansatz, um in Incidents schneller von Symptomen zu belastbarer Evidenz zu kommen. Kubernetes abstrahiert vieles so konsequent, dass Netzwerkprobleme im Alltag „unsichtbar“ werden – bis es knallt: Pods erreichen Services nicht, DNS wirkt flaky, Verbindungen resetten, oder Latenzspitzen tauchen scheinbar ohne Ursache auf. Wer dann nur „Kubernetes ist kaputt“ sagt, verliert Zeit. Wer hingegen das CNI (Container Network Interface) systematisch auf OSI-Layer abbildet, kann sauber trennen: Ist es ein physischer/virtueller Link (Layer 1/2), ein Routing- oder IP-Problem (Layer 3), ein Transport- und State-Problem (Layer 4) oder eher Policy/Ingress/Applikation (Layer 5–7)? Genau hier hilft ein OSI-Mindset: Es macht die Diagnose reproduzierbar, die Kommunikation zwischen Platform, SRE, Security und Netzwerkteam präziser und verhindert typische Fehlinterpretationen wie „SecurityPolicy muss falsch sein“, obwohl eigentlich Conntrack oder MTU zuschlägt. In diesem Artikel geht es darum, wie Sie CNI-Komponenten, Datenpfade und typische Failure Modes auf die OSI-Schichten mappen – inklusive konkreter Signale, die Sie in Telemetrie und Logs suchen sollten.

Warum OSI-Denken im Kubernetes-Netzwerkbetrieb funktioniert

Das OSI-Modell ist kein Ersatz für Kubernetes-Know-how, aber eine nützliche Struktur. Kubernetes Networking ist eine Kombination aus Linux-Netzwerkprimitive (Interfaces, Routing, Netfilter), CNI-Plugins (z. B. Calico, Cilium, Flannel), Service-Mechanik (kube-proxy oder eBPF) und Cloud-Underlay (VPC/VNet, Load Balancer, Firewalls). Ohne Struktur springen Teams oft zwischen Ebenen hin und her: Man prüft NetworkPolicy, dann DNS, dann Load Balancer, dann wieder iptables – und verliert Minuten bis Stunden. Eine OSI-Mapping-Logik schafft eine feste Reihenfolge: Zuerst die Basis (Link/Interface), dann IP-Erreichbarkeit, dann Transportzustand, dann Policies und höhere Protokolle.

• Weniger kognitive Last: Eine feste Schichtenlogik ersetzt „Trial and Error“ durch systematische Eingrenzung.
• Bessere Team-Schnittstellen: Sie können klar benennen, ob es ein Underlay-, Node- oder Service-Problem ist.
• Schnellere Evidenz: Pro Layer existieren typische Beweise (Drops, Routing, Retransmits, Denies).

Als Referenz für das grundlegende Kubernetes-Netzwerkmodell lohnt sich der Blick auf den Anchor-Text Kubernetes Networking Concepts. Für die CNI-Spezifikation ist Container Network Interface (CNI) die primäre Quelle.

Grundbegriffe: Was CNI in Kubernetes wirklich macht

CNI ist kein „Netzwerkprodukt“, sondern ein Vertrag: Kubernetes (konkret der Kubelet) ruft ein CNI-Plugin auf, wenn ein Pod-Netzwerknamespace erzeugt wird. Das Plugin sorgt typischerweise dafür, dass der Pod ein Interface bekommt, eine IP-Adresse zugewiesen wird und Routing/Policy so eingerichtet ist, dass der Pod im Cluster kommunizieren kann. Alles, was darüber hinaus passiert (Services, Ingress, L7-Routing), ist nur teilweise CNI – aber fast immer eng gekoppelt.

• Pod Interface: Meist über ein veth-Pair (Pod-Interface ↔ Host-Interface).
• IPAM: IP Address Management (IP-Vergabe aus Pod-CIDR oder IP-Pools).
• Routing/Encapsulation: L3-Routing direkt oder Overlay (VXLAN, Geneve), je nach Plugin/Modus.
• Policy: NetworkPolicy-Implementierung (iptables, eBPF, Envoy-Integration, etc.).

Wichtig für SREs: CNI ist Teil des Datenpfads. Wenn das CNI degradieren kann, dann kann es auch Latenz, Drops und Retries auslösen – oft ohne klare Fehlermeldung auf Applikationsebene.

OSI-Layer 1: Der Link ist virtuell, die Physik bleibt real

In Kubernetes sehen Sie selten echte Layer-1-Signale wie Kabel, Optiken oder ToR-Switches. Dennoch ist Layer 1 relevant, weil Node-NICs, Hypervisor-Hosts, Cloud-Underlay und virtuelle Switches die Basis für alles Weitere bilden. Für SREs ist das Ziel nicht, Layer 1 zu „fixen“, sondern Layer-1- oder Underlay-Degradation zu erkennen und deren Blast Radius einzugrenzen.

• Node-Interface-Errors: CRC/Frame-Errors, RX/TX-Errors, Drops auf der NIC (sofern sichtbar).
• Queueing/Saturation: Interface-Queues, Softnet-Backlog, CPU-SoftIRQ-Last (Hinweis auf Paketverarbeitung am Limit).
• Cloud-Indikatoren: Provider-Status, AZ-spezifische Degradationsmeldungen, auffällige Host-Replacements.
• Symptom-Muster: Viele Services gleichzeitig betroffen, aber nur auf bestimmten Nodes/Nodepools.

Wenn Sie tiefer in Linux-Netzwerkpfade und Queueing einsteigen möchten, ist der Anchor-Text tc (traffic control) hilfreich, weil viele Latenz- und Drop-Phänomene letztlich in Queues sichtbar werden.

OSI-Layer 2: veth, Bridge, ARP/ND und „L2-Effekte“ im Cluster

Layer 2 in Kubernetes ist selten „klassisches Ethernet“ über Switches, aber L2-Mechaniken wirken trotzdem: veth-Pairs verhalten sich wie virtuelle Kabel, Bridges verbinden Interfaces, ARP (IPv4) und Neighbor Discovery (IPv6) erzeugen Broadcast-/Multicast-ähnliche Last, und Overlays kapseln L2/L3-Verkehr. Je nach CNI-Modus kann ein Cluster stärker „bridged“ oder stärker „routed“ sein.

Typische CNI-Setups auf Layer 2

• Bridge-basierte Modelle: Pods hängen an einer Linux-Bridge (oder OVS), NAT/iptables regeln den Rest.
• Routed Modelle: Pod-Traffic wird primär geroutet; L2 dient nur lokal auf dem Node.
• Overlay-Modelle: Ein Tunnel-Interface (z. B. VXLAN) kapselt Pod-Traffic über das Underlay.

Signale und Failure Modes

• ARP/ND-Pressure: Hohe Rate an Neighbor-Requests kann bei Scale zu Drops oder CPU-Last führen.
• MAC/Neighbor-Churn: Viele wechselnde Endpunkte (Pods) erhöhen Tabellen- und Cache-Druck.
• MTU-Mismatch: „Works on small payloads“ ist ein Klassiker bei Tunneln und falscher MTU.

Für Overlays ist der technische Hintergrund zu VXLAN über den Anchor-Text VXLAN (RFC 7348) eine solide Referenz. Das hilft, Encapsulation-Overhead und MTU-Effekte sauber zu erklären.

OSI-Layer 3: Pod-CIDRs, Routing, Encapsulation und Service-Erreichbarkeit

Layer 3 ist der Kern des CNI: IP-Adressierung, Routingtabellen, Tunnel-Endpunkte und die Frage, ob ein Pod-IP-Endpunkt erreichbar ist. Die wichtigste Kubernetes-Regel lautet: Jeder Pod kann jeden anderen Pod ohne NAT erreichen (Netzwerkmodell). Wie das umgesetzt wird, unterscheidet sich jedoch stark.

Mapping: Was auf Layer 3 typischerweise zu CNI gehört

• IPAM und Pools: Vergabe von Pod-IPs, ggf. aus Node-spezifischen Pod-CIDRs.
• Node-Routing: Routen zu Pod-Netzen anderer Nodes (direkt, via BGP, via Overlay).
• Encapsulation: VXLAN/Geneve-IP-in-IP, um Pod-Netze über Underlay zu transportieren.
• Cloud-Integration: Routen-Propagation oder ENI-basierte Modelle, je nach Plattform.

Praktische Beweise auf Layer 3

• Pod-IP Ping/ICMP-Tests: Nur als Indiz, nicht als vollständiger Beweis (ICMP kann anders behandelt werden).
• Routingtabellen: Fehlt die Route zu einem Pod-CIDR, ist der Fehler oft klar, aber die Ursache (Config/Controller) nicht.
• Overlay-Tunnel-Health: Tunnel-Interface up/down, Drops, Encapsulation-Fehler, MTU-Probleme.
• Asymmetrie: Hinweg ok, Rückweg falsch – sichtbar als sporadische Timeouts.

Wenn Sie mit Calico arbeiten, ist der Anchor-Text Calico Architektur und Routing hilfreich, weil dort BGP, IP-in-IP und VXLAN-Modi praxisnah beschrieben sind. Für eBPF-zentrierte CNIs ist Cilium Dokumentation eine gute Quelle, insbesondere zu Routing und Service-Handling ohne klassischen kube-proxy.

OSI-Layer 4: TCP/UDP, Conntrack, NAT und warum „Netzwerkprobleme“ oft State-Probleme sind

Auf Layer 4 entscheidet sich, ob eine Verbindung stabil ist: TCP-Handshake, Retransmissions, Windowing, Timeouts und der Umgang mit „State“ im Datenpfad. In Kubernetes ist Layer 4 stark von Netfilter/iptables, Conntrack und ggf. eBPF-Implementierungen geprägt. Viele Cluster-Ausfälle, die wie „random disconnects“ wirken, sind in Wahrheit Conntrack-Sättigung, Port Exhaustion oder fehlerhafte Timeout-Ketten (Client ↔ Proxy ↔ Service).

Conntrack als zentraler Layer-4-Knoten

Conntrack (Connection Tracking) speichert Zustände zu Verbindungen. Das ist nötig für NAT und oft auch für Service-Routing, kann aber bei Lastspitzen zum Bottleneck werden. Wenn Conntrack voll ist, sehen Sie Drops, Timeouts, unerklärliche Retries – und häufig nur sehr generische Fehlermeldungen in der App.

• Beweis-Signal: Conntrack current nahe max, steigende drop counters.
• Symptom: Verbindungen brechen „random“ ab, neue Connections scheitern häufiger als bestehende.
• Kontext: Besonders kritisch bei vielen kurzlebigen Verbindungen (z. B. falsches Connection Pooling).

Für Linux-Conntrack ist der Anchor-Text conntrack(8) eine nützliche Referenz, um Begriffe wie Table Size, States und Timeouts korrekt einzuordnen.

MTU- und Encapsulation-Overhead rechnerisch greifbar machen

Gerade bei Overlay-Netzen ist es hilfreich, den maximalen Payload zu kennen, der ohne Fragmentierung transportiert werden kann. Das verhindert Fehlersuche an der falschen Stelle, wenn große Responses droppen, kleine aber funktionieren.

$\mathrm{MSS}=(\mathrm{MTU}-\mathrm{IP}-\mathrm{TCP}-\mathrm{Overhead})$

In der Praxis heißt das: Wenn Encapsulation-Overhead steigt und die effektive MTU nicht angepasst ist, entstehen Fragmentierung, Drops oder auffällige Retransmissions – typische Layer-4-Signale.

OSI-Layer 5: „Session“-Effekte im Kubernetes-Datenpfad

Layer 5 wird in Kubernetes selten explizit benannt, aber operative Session-Effekte existieren: Keepalive-Verhalten, Connection Reuse, Affinity-Mechanismen, Long-lived Connections (WebSocket, gRPC) und deren Interaktion mit Load Balancern oder Proxies. Für SREs ist der entscheidende Punkt: Ein Teil der „Session“-Stabilität entsteht nicht in der App, sondern durch den Transport- und Proxy-Pfad.

• Keepalive vs. Idle Timeout: Unterschiedliche Defaults in Client, Ingress und Cloud-LB führen zu „random resets“.
• Long-lived Connections: gRPC/WebSockets reagieren empfindlich auf NAT/Conntrack-Timeouts und LB-Rebalances.
• Affinity in Services: Session Affinity (ClientIP) kann Hotspots erzeugen und Failover erschweren.

OSI-Layer 6: TLS, mTLS und warum CNI-Diagnosen hier oft enden

TLS gehört formal nicht zum CNI, aber in der Realität tauchen viele „Networking“-Tickets als TLS-Probleme auf: Zertifikate abgelaufen, Chain unvollständig, SNI/ALPN-Mismatch, mTLS-Policy-Fehler im Service Mesh. Das OSI-Mapping hilft, solche Fälle nicht als CNI-Bug zu verfolgen, wenn Transport (L4) ok ist, aber Handshakes (L6) scheitern.

• Handshake-Fehlerquoten: Unterscheiden Sie „connect failed“ (L4) von „handshake failed“ (L6).
• mTLS Failure Modes: unknown CA, SAN mismatch, policy denies.
• Offload vs. End-to-End: TLS-Offload verschiebt Sichtbarkeit und verändert Debugging-Pfade.

Als technische Basis ist der Anchor-Text TLS 1.3 (RFC 8446) sinnvoll, um Handshake-Phasen und typische Fehlermuster korrekt zuzuordnen.

OSI-Layer 7: Services, Ingress und „Netzwerk-Symptome“ mit HTTP-Semantik entlarven

Layer 7 ist nicht CNI, aber ohne L7-Verständnis bleibt das OSI-Mapping unvollständig. Ein Beispiel: 503 kann „Upstream down“ bedeuten, aber auch „Policy blockt“, „Endpoints leer“, „Read timeout“ oder „Retry-Budget erschöpft“. Für SREs ist entscheidend, L7-Signale als Evidenz zu nutzen, nicht als voreilige Ursache.

• Statuscode-Pattern: 502/503/504 getrennt betrachten, dazu 429/408 und client-abgebrochene Requests.
• Retries und Idempotency: Retries können Fehler verstärken (Retry Storm) und Tail Latency erhöhen.
• Ingress vs. Service Mesh: Wo endet Observability? Wo beginnt Verschleierung durch Proxying?

Der Datenpfad in der Praxis: Pod-to-Pod, Pod-to-Service, Pod-to-External

Ein OSI-Mapping wird besonders greifbar, wenn Sie es auf drei Standardpfade anwenden. Jeder Pfad hat typische Stolperstellen und damit typische „Beweisstellen“.

Pod-to-Pod (innerhalb des Clusters)

• L2/L3: veth/bridge, Pod-IP, Routen/Overlay-Tunnel.
• L4: Conntrack, Retransmissions, Port-/State-Sättigung.
• Policy: NetworkPolicy-Denies (iptables/eBPF), oft als Timeout sichtbar.

Pod-to-Service (ClusterIP/NodePort/LoadBalancer intern)

• Service-Mechanik: kube-proxy iptables/ipvs oder eBPF-basierte Service Translation.
• Endpoint-Health: „Service existiert“, aber keine Endpoints (Deployment down, readiness falsch).
• Hairpin/Looping: Sonderfälle bei Pod → Service → Pod auf demselben Node.

Pod-to-External (Internet, SaaS, On-Prem)

• NAT/Firewall: Port Exhaustion, NAT-Gateway-Bottlenecks, egress policies.
• DNS/TLS: Externe Abhängigkeiten fallen häufig als „Netzwerkproblem“ auf.
• Asymmetrie: Rückweg über andere Route, VPN/PrivateLink-Reset-Muster.

Troubleshooting-Checkliste: Pro OSI-Layer die ersten fünf Fragen

Diese Checkliste ist bewusst kurz gehalten, damit sie in echten Incidents funktioniert. Sie ersetzt kein Runbook, aber sie verhindert die typischen Diagnose-Sprünge.

Layer 1

• Gibt es node-spezifische Interface-Errors oder Drops?
• Ist das Problem auf bestimmte Nodes/Nodepools/AZs begrenzt?
• Sehen Sie Saturation (SoftIRQ/Queueing) während der Fehler?
• Gibt es Provider-Degradationshinweise für die betroffene Region/AZ?
• Korrelieren Fehler mit Host-Replacements oder Live-Migrations?

Layer 2

• Gibt es MTU-Abweichungen zwischen Pod, Node und Tunnel-Interfaces?
• Ist ARP/ND auffällig hoch (Scale, Storms, Neighbor-Churn)?
• Sehen Sie Drops/Errors auf veth/bridge/tunnel Interfaces?
• Ändert sich das Verhalten bei kleinen vs. großen Payloads?
• Treten Probleme nur in bestimmten CNI-Modi/Encapsulation-Setups auf?

Layer 3

• Hat der betroffene Pod eine korrekte IP und Route?
• Existiert die Route zum Ziel-Pod-CIDR (oder Tunnel ist up)?
• Gibt es Hinweise auf asymmetrisches Routing?
• Gibt es Security-/Firewall-Drops auf IP-Ebene (Flow Logs)?
• Sind IP-Pools erschöpft oder kollidieren CIDRs (Hybrid/Peering)?

Layer 4

• Steigen TCP Retransmissions, Timeouts oder Resets an?
• Ist Conntrack nahe am Limit oder steigen Conntrack-Drops?
• Gibt es Port Exhaustion oder ungewöhnlich viele kurzlebige Connections?
• Ist die Timeout-Kette konsistent (Client/Ingress/Upstream/NAT)?
• Unterscheiden sich Symptome zwischen TCP und UDP (z. B. DNS)?

Layer 5–7

• Wirkt es wie Session-/Keepalive-Thema (Long-lived, Idle Timeout)?
• Scheitert TLS im Handshake (L6) oder schon beim Connect (L4)?
• Sind 5xx/4xx Muster konsistent mit Upstream-Down, Timeout oder Misroute?
• Gibt es Retry-Amplifikation, die Latenz und Errors verstärkt?
• Zeigt Tracing, wo die Zeit verbrannt wird (Client/Proxy/Upstream)?

NetworkPolicy richtig einordnen: Policy-Issue oder darunterliegender Layer?

NetworkPolicy-Probleme sind häufig, aber die Symptome sind tückisch: Ein Policy-Deny sieht oft exakt wie Paketverlust oder Routingfehler aus – nämlich als Timeout. Das OSI-Mapping hilft: Wenn L3/L4-Konnektivität grundsätzlich funktioniert (z. B. andere Ports/Services), aber bestimmte Flows immer ausfallen, ist Policy eine starke Hypothese. Wenn dagegen Flows sporadisch ausfallen und gleichzeitig Conntrack/Drops steigen, ist Policy eher sekundär.

• Beweis für Policy: Explizite Deny-Logs (je nach CNI), Counter pro Rule, reproduzierbare Blockade.
• Hinweis auf darunterliegende Ursache: Sporadische Drops, Korrelation mit Lastspitzen, Node-spezifische Muster.

Was SREs aus „CNI ist kaputt“ als bessere Aussage machen sollten

Im Incident zählt nicht das Label, sondern die präzise Aussage. „CNI ist kaputt“ ist zu grob. Ein OSI-basiertes Statement ist deutlich nützlicher, weil es die nächste Aktion vorgibt: Owner, Runbook, Mitigation, Eskalation.

• Besser als „Netzwerk spinnt“: „Layer 4 zeigt Retransmissions + Conntrack nahe Limit auf Nodepool X; Pod-to-Service betroffen.“
• Besser als „Policy falsch“: „Flow wird konsistent geblockt, Deny-Counter steigt auf Regel Y; L3-Routing ist stabil.“
• Besser als „Kubernetes down“: „Overlay-Tunnel Drops steigen nach MTU-Change; große Payloads betroffen.“

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.