CNI 101: Komponenten auf OSI-Layer mappen

CNI 101: Komponenten auf OSI-Layer mappen – das klingt zunächst theoretisch, ist aber in Kubernetes-Praxis einer der schnellsten Wege, um Netzwerkprobleme strukturiert zu verstehen. Viele Fehlerbilder in Clustern wirken „zufällig“: Pods erreichen manche Ziele, andere nicht; DNS ist sporadisch langsam; NetworkPolicies greifen nicht wie erwartet; oder die MTU macht bei bestimmten Workloads Ärger. Wenn Sie CNI (Container Network Interface) und die dazugehörigen Bausteine sauber den OSI-Schichten zuordnen, wird aus Chaos ein nachvollziehbares System: Sie erkennen, ob ein Problem auf Layer 2 (Bridging/VLAN/VXLAN), Layer 3 (Routing/IPAM), Layer 4 (Ports/Conntrack/Service-LB) oder Layer 7 (DNS/Proxies) entsteht – und welche Komponente im Cluster dafür zuständig ist. Dieser Artikel erklärt die wichtigsten CNI-Bausteine (Plugins, IPAM, veth, Bridge, Overlay, eBPF, kube-proxy, CoreDNS, Ingress) und ordnet sie in das OSI-Modell ein. Ziel ist, dass Sie als Einsteiger oder Fortgeschrittener nicht nur Begriffe kennen, sondern typische Datenpfade in Kubernetes „lesen“ können: vom Pod-Interface bis zum externen Ziel, inklusive Service-NAT, Policy-Enforcement und Observability.

Was CNI in Kubernetes wirklich ist

CNI steht für Container Network Interface und beschreibt eine Spezifikation, wie Container-Runtimes (bzw. Kubernetes über Komponenten wie kubelet) Netzwerk-Plugins aufrufen, um einem Pod Netzwerkfunktionen bereitzustellen. Wichtig: CNI ist nicht „das Netzwerk“, sondern die standardisierte Schnittstelle, über die ein Plugin die Netzwerkkonnektivität für Pods herstellt. Typisch ist ein Lifecycle: Beim Erstellen eines Pods ruft kubelet das CNI-Plugin mit ADD auf, beim Entfernen mit DEL. Das Plugin richtet dann Interfaces, IP-Adressen, Routen und ggf. Regeln für Policy/Encapsulation ein.

• CNI-Spezifikation: definiert Eingaben/Outputs und das Plugin-Verhalten, nicht die konkrete Implementierung.
• CNI-Plugin: implementiert die Netzwerkerstellung (z. B. veth, Bridge, Routing, Overlay).
• IPAM: separater Baustein für IP-Adressvergabe und -Verwaltung.

Offizielle Grundlagen finden Sie in der CNI-Dokumentation und in den Kubernetes-Konzepten rund um Netzwerk und DNS unter Kubernetes Networking Concepts.

OSI-Modell als Werkzeug: Warum es für CNI hilfreich ist

Das OSI-Modell ist kein „Schaltplan“, sondern ein Denkrahmen. Kubernetes-Netzwerke nutzen in der Realität häufig mehrere Schichten gleichzeitig – etwa wenn ein Overlay auf Layer 2/3 aufgebaut ist, während Policy-Enforcement auf Layer 3/4 passiert und Service-Routing zusätzlich NAT-Mechanismen nutzt. Dennoch hilft die Schichtung enorm, weil Sie Ursachen eingrenzen können:

• Layer 2 Probleme zeigen sich oft als ARP-/MAC-/Bridging-Effekte, Broadcast-Domänen oder Encapsulation-Fehler.
• Layer 3 Probleme betreffen IP-Routing, Subnetze, IPAM-Overlaps, fehlende Routen oder falsche Next Hops.
• Layer 4 Probleme betreffen Ports, Conntrack, NAT, Load Balancing, Timeouts oder SYN-Fehlerbilder.
• Layer 7 Probleme betreffen DNS, HTTP-Fehler, Proxies, Ingress, mTLS, Service Mesh.

Der Trick ist, Kubernetes-Komponenten nicht nur „im Kopf“ zu haben, sondern sie als Schicht-Module zu betrachten, die gemeinsam einen Datenpfad bauen.

Die Kernkomponenten einer CNI-Implementierung

Unabhängig davon, ob Sie Calico, Cilium, Flannel, Weave Net oder ein Cloud-CNI nutzen: Bestimmte Bausteine tauchen fast immer auf. Diese Bausteine lassen sich gut in OSI-Schichten einsortieren, auch wenn einzelne CNIs mehrere Rollen gleichzeitig übernehmen.

• Pod-Interfaces: veth-Paare, die Pod-Namespace und Node-Namespace verbinden.
• Host-Switching: Linux Bridge oder eBPF-basierte Weiterleitung statt klassischem Bridging.
• IPAM: Zuweisung von Pod-IP, Subnetzen, Routen.
• Overlay/Encapsulation: VXLAN/Geneve/GRE oder native Routing-Modelle ohne Overlay.
• Policy-Enforcement: iptables/nftables oder eBPF-Regeln für NetworkPolicy/ACL-Logik.
• Service-Routing: kube-proxy (iptables/ipvs) oder eBPF-Service-LB.
• DNS: CoreDNS als Standard für Service Discovery.

Layer 1 und Layer 2: Physik, Ethernet und lokale Weiterleitung

In Kubernetes denken viele sofort an IP und Routing, aber die Basis ist weiterhin Ethernet (in den meisten Umgebungen). Auf OSI Layer 1/2 liegen Hardware, NIC-Treiber, Link-Speed, MTU auf dem Underlay und die lokale Weiterleitung auf dem Node. Auch wenn Pods virtuelle Interfaces nutzen, laufen am Ende Frames über die physische Netzwerkkarte.

Welche CNI-Bausteine auf Layer 2 wirken

• veth-Paare: virtuelles Ethernet, verbindet Pod und Host (Layer 2 Mechanik, auch wenn darüber IP läuft).
• Linux Bridge: klassischer Layer-2-Switch im Linux-Kernel (z. B. bei einfachen CNIs).
• ARP/ND: Address Resolution (IPv4 ARP, IPv6 Neighbor Discovery) für lokale Zustellung.
• Overlay-Encapsulation: VXLAN/Geneve kapselt oft Ethernet/Layer-2-Semantik in UDP ein.

Wenn auf Layer 2 etwas klemmt, sehen Sie häufig Symptome wie: Pods verlieren sporadisch Konnektivität nach Node-Wechsel, ARP-Caches wirken „komisch“, oder der Traffic bricht bei großen Paketen (MTU/Fragmentierung) ein. Gerade Overlays sind empfindlich gegenüber MTU-Differenzen im Underlay.

Layer 3: IP-Adressierung, Routing und Pod-to-Pod Connectivity

Der wichtigste OSI-Layer für CNI ist Layer 3: Hier entscheidet sich, wie Pods IPs bekommen und wie IP-Pakete zwischen Nodes geroutet werden. Kubernetes fordert grundsätzlich, dass jeder Pod eine eigene IP erhält und Pods untereinander IP-Konnektivität haben. Wie das umgesetzt wird, ist CNI-spezifisch: per Overlay (Encapsulation) oder per Underlay-Routing (BGP/Cloud-Routing/Native).

IPAM: Das Herz der Adressvergabe

IPAM (IP Address Management) ist häufig als separates CNI-Plugin implementiert. Es vergibt Pod-IP-Adressen aus einem Pool, verwaltet Reservierungen und sorgt dafür, dass IPs nicht kollidieren. In Cloud-Umgebungen existieren Varianten, bei denen Pod-IPs direkt aus VPC/VNet-Adressräumen kommen (Cloud-CNI), wodurch Layer-3-Integration mit dem Underlay enger wird.

• Lokales IPAM: Pod-CIDRs pro Node, IPs aus Node-Pool (typisch bei Overlays).
• Underlay-IPAM: Pod-IPs als „echte“ VPC/VNet-IP (stärkerer Bezug zur Cloud-Routingdomäne).
• Risiko: Overlapping CIDRs zwischen Clustern/Netzen führen zu schwer debuggbaren Routingfehlern.

Routing-Modelle: Overlay vs. Native Routing

• Overlay: Pod-IP bleibt intern, zwischen Nodes wird encapsulated (häufig VXLAN oder Geneve). Vorteil: Underlay muss Pod-Routen nicht kennen. Nachteil: Overhead, MTU-Themen, Observability komplexer.
• Native Routing: Underlay kennt Pod-Routen (z. B. via BGP). Vorteil: weniger Overhead, klarere Datenpfade. Nachteil: mehr Anforderungen an Netzwerkintegration und Governance.

Layer-3-Dokumentation und Hintergründe zu Kubernetes-Netzwerkmodellen finden Sie in den Kubernetes Networking Concepts sowie in CNI-spezifischen Dokumentationen (z. B. Calico oder Cilium), je nach Umgebung.

Layer 4: Ports, Conntrack, NAT und Services

Auf OSI Layer 4 wird es für den Alltag besonders relevant: Hier liegen TCP/UDP, Port-Mapping, Session-State und viele der Symptome, die Teams als „App-Problem“ wahrnehmen. Kubernetes Services (ClusterIP, NodePort, LoadBalancer) sind im Kern Layer-4-Konstrukte: Sie bieten einen stabilen virtuellen Endpunkt (VIP) und verteilen Traffic auf Pod-Endpunkte.

kube-proxy: Service-Routing klassisch auf Layer 4

In vielen Clustern übernimmt kube-proxy die Umsetzung von Services über iptables oder IPVS. Dabei werden Regeln auf dem Node installiert, die den Traffic an die passenden Pod-Endpunkte weiterleiten. Das ist Layer-4-nah, weil die Entscheidung oft anhand von Ziel-IP (Service VIP) und Zielport getroffen wird.

• iptables-Modus: weit verbreitet, robust, kann bei sehr großen Regelmengen komplex werden.
• IPVS-Modus: effizienter für große Setups, nutzt Kernel-LB-Mechanismen.

Offizielle Hintergründe bietet die Kubernetes-Dokumentation zu Services unter Kubernetes Services.

eBPF-basierte Service-LBs: Layer-4-Funktionen ohne kube-proxy

Moderne CNIs (insbesondere eBPF-basierte) können Service-LB und Policy-Enforcement teilweise ohne kube-proxy abbilden. Das ändert nicht den OSI-Layer (weiterhin Layer 4), aber die Implementierung: Statt iptables-Regeln entscheidet eBPF-Logik im Kernel über Weiterleitung und NAT. Das ist oft performanter und beobachtbarer, erfordert aber sauberes Verständnis, wo genau NAT, DSR oder SNAT passieren.

Conntrack und Timeouts: Häufige Layer-4-Fallen

• Conntrack-Table voll: neue Verbindungen scheitern, Symptome sind sporadisch und schwer zuzuordnen.
• Asymmetrische Pfade: Rückverkehr nimmt anderen Weg, Conntrack-State passt nicht mehr.
• NAT-Kaskaden: mehrere NAT-Stufen (Service-NAT, egress-NAT) erschweren Debugging und erhöhen Fehlerrisiko.

Wenn Sie auf Layer 4 sauber arbeiten, prüfen Sie bei Fehlerbildern immer: Gibt es Drop-Spikes? Sind Timeouts konsistent für bestimmte Ziele/Ports? Ändert sich das Verhalten, wenn Sie direkte Pod-IP statt Service-IP nutzen?

Layer 5 und Layer 6: Session, Verschlüsselung und Proxies

In Kubernetes tauchen Layer 5/6 oft indirekt auf: Sessions, TLS, mTLS, Zertifikate, und Proxies, die Verbindungen terminieren oder neu aufbauen. Streng nach OSI sind Session- und Presentation-Layer selten „eigene“ Komponenten in Linux-Netzwerken, aber praktisch ist das ein nützlicher Zwischenraum: Viele Effekte, die wie Netzwerkprobleme wirken, sind tatsächlich TLS- oder Proxy-Verhalten.

• TLS-Termination: Ingress Controller oder Service Mesh Gateways terminieren TLS und erstellen neue Verbindungen.
• mTLS: Sidecars verschlüsseln Ost-West-Traffic; dadurch ändern sich Latenz, MTU-Empfindlichkeit und Fehlerbilder.
• HTTP/2 und Connection Reuse: beeinflusst, wie viele TCP-Sessions tatsächlich entstehen (Conntrack-Last, NAT-Verhalten).

Layer 7: DNS, Ingress und Service Mesh

Auf Layer 7 liegen Kubernetes-typische Komponenten, die oft fälschlich als „CNI-Thema“ behandelt werden, obwohl sie oberhalb der reinen Netzwerkbereitstellung arbeiten. Dazu gehören DNS (CoreDNS), Ingress Controller (HTTP Routing) und Service Mesh (Traffic Policies, Telemetry, mTLS). Für Troubleshooting ist das Mapping wichtig: Wenn Pod-to-Pod-IP-Ping funktioniert, aber der Service-Name nicht auflösbar ist, sind Sie eher bei DNS/Layer 7 als bei CNI.

CoreDNS: Service Discovery und Namensauflösung

CoreDNS liefert die Namensauflösung für Services und Pods (je nach Setup). Viele „Netzwerkprobleme“ sind in Wahrheit DNS-Probleme: falsche Suchdomänen, Timeouts, zu kleine UDP-Pakete mit Fragmentierung, oder überlastete DNS-Pods. Kubernetes erklärt DNS-Grundlagen und CoreDNS-Integration unter DNS for Services and Pods.

Ingress Controller: HTTP/HTTPS-Routing über Layer 7

Ingress ist ein Layer-7-Routing-Konzept: Hostnames, Pfade, TLS, Header-Manipulation. Wenn Ingress nicht funktioniert, kann die Ursache zwar unterhalb liegen (z. B. Service/Endpoints), aber die Fehlerbilder sind häufig HTTP-spezifisch (404/502/504). Das Mapping hilft: Sie prüfen zuerst, ob Service und Endpoints auf Layer 4 erreichbar sind, bevor Sie an CNI schrauben.

CNI-Komponenten als OSI-Mapping: Eine praktische Zuordnung

Die folgende Zuordnung ist bewusst pragmatisch: Viele Komponenten wirken über mehrere Schichten, aber es gibt eine „primäre“ Ebene, auf der sie in der Regel verstanden und debuggt werden sollten.

• veth, Bridge, ARP/ND: primär Layer 2
• IPAM, Pod CIDRs, Routen, BGP: primär Layer 3
• kube-proxy, Service VIPs, NodePort, Conntrack, NAT: primär Layer 4
• TLS/mTLS, Sidecar-Proxies (Transportaspekt): primär Layer 5/6
• CoreDNS, Ingress, Service Mesh Policies (HTTP): primär Layer 7

Als Einstieg in CNI- und Plugin-Mechanik ist zudem die Spezifikation selbst hilfreich, weil sie den ADD/DEL-Flow und die Konfigurationsstruktur erklärt: CNI Spec und Referenzimplementierung.

Beispiel-Datenpfade: So hilft das OSI-Mapping im Alltag

Am meisten Wert liefert das Mapping, wenn Sie einen konkreten Datenpfad gedanklich „durchlaufen“. Zwei typische Pfade sind: Pod zu Pod (clusterintern) und Pod zu extern (egress). In beiden Fällen können Sie pro OSI-Layer kontrollieren, ob die erwartete Funktion vorhanden ist.

Pod zu Pod auf unterschiedlichen Nodes

• Layer 2: veth im Pod ist up, Host-Interface existiert, lokale Weiterleitung funktioniert.
• Layer 3: Pod-IP ist korrekt, Route zum Ziel-Pod-Netz existiert (Overlay oder Underlay-Routing).
• Layer 4: Falls über Service: kube-proxy/eBPF leitet an Endpoints, Conntrack passt.
• Layer 7: Falls über Namen: DNS löst Service korrekt auf.

Wenn der direkte Zugriff auf die Pod-IP funktioniert, aber der Service nicht, ist das ein Layer-4-Thema (Service-Mechanik) oder ein Endpoint-Thema – nicht zwingend CNI/Layer 3.

Pod zu externem Ziel (Egress)

• Layer 3: Default-Route aus dem Pod, Routing am Node, ggf. SNAT-Regeln.
• Layer 4: NAT/Conntrack für ausgehende Sessions, Timeouts und Statefulness.
• Layer 2/MTU: bei Tunneln/Overlays: effektive MTU kann Drops verursachen, besonders bei TLS/HTTPS.

Viele „komische“ Egress-Probleme sind in Wahrheit eine Mischung aus Layer 3 (Routing), Layer 4 (SNAT/Conntrack) und Layer 2/MTU (Encapsulation).

NetworkPolicy: Wo sie im OSI-Modell sitzt

Kubernetes NetworkPolicy wird häufig als „Firewall für Pods“ verstanden. Technisch ist sie primär Layer 3/4: Sie beschreibt erlaubte Quellen/Ziele, Ports und Protokolle. Das CNI muss NetworkPolicy unterstützen, sonst bleibt sie wirkungslos. Implementierungen setzen das meist über iptables/nftables oder eBPF um. Das ist ein wichtiger Governance-Punkt: Wenn Policies erwartet werden, muss die CNI-Auswahl und -Konfiguration das erfüllen.

• Layer 3: IP-basierte Regeln, CIDRs, Pod-/Namespace-Selektoren (übersetzt in konkrete IPs/Identitäten).
• Layer 4: Port/Protokoll-Regeln (TCP/UDP) und Zustandsverhalten.

Zur Einordnung ist die offizielle Kubernetes-Dokumentation zu Network Policies eine solide Grundlage.

Observability: Welche Signale passen zu welchem Layer

Um schnell zum Root Cause zu kommen, sollten Sie Ihre Messpunkte ebenfalls nach OSI-Layern denken. Das verhindert, dass Sie stundenlang an einer Stelle suchen, an der Sie die nötigen Signale gar nicht sehen können.

• Layer 2 Signale: Interface-Errors, Drops, MTU/Fragmentierung, ARP/ND-Anomalien.
• Layer 3 Signale: Routing-Tabellen, Pod-CIDR-Zuordnung, Overlay-Tunnel-Status, BGP-Sessions.
• Layer 4 Signale: Conntrack-Auslastung, NAT-Statistiken, TCP Retransmits, SYN-Backlog.
• Layer 7 Signale: DNS-Latenz, NXDOMAIN-Raten, HTTP 5xx, Ingress-Logs, Proxy-Telemetrie.

Ein praktischer Tipp: Wenn möglich, trennen Sie Tests in „IP erreichbar“ (Layer 3), „Port erreichbar“ (Layer 4) und „Name/HTTP funktioniert“ (Layer 7). Diese Staffelung spart in incidentnahen Situationen sehr viel Zeit.

Typische Missverständnisse bei CNI und OSI

• „CNI ist nur Layer 3“: Viele CNIs beeinflussen Layer 2 (veth/bridge/overlay) und Layer 4 (Service-LB/Policy).
• „Service-Probleme sind immer CNI-Probleme“: Services sind primär Layer 4; DNS/Ingress sind Layer 7.
• „NetworkPolicy ist überall gleich“: Policies hängen vom CNI ab und werden unterschiedlich umgesetzt.
• „Overlay ist immer schlechter“: Overlay kann Governance vereinfachen, aber erfordert MTU-Disziplin und gute Observability.
• „Ping reicht als Test“: Ping testet ICMP, nicht TCP/UDP oder Service-NAT; Layer-4-Probleme bleiben unsichtbar.

Weiterführende Quellen für CNI, Kubernetes Networking und OSI-Bezug

• CNI Dokumentation: Konzepte und Plugins
• CNI Spezifikation und Referenzprojekt
• Kubernetes Networking Concepts: Anforderungen und Modelle
• Kubernetes Services: ClusterIP, NodePort, LoadBalancer
• DNS for Services and Pods: CoreDNS und Service Discovery
• Kubernetes Network Policies: L3/L4-Policy-Grundlagen

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.