Site icon bintorosoft.com

CNI 101: Komponenten auf OSI-Layer mappen

Red Snapper

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.

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:

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.

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

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.

Routing-Modelle: Overlay vs. Native Routing

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.

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

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.

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.

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

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)

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.

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.

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

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

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:

Lieferumfang:

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.

 

Exit mobile version