February 14, 2026

OSI-Modell für Kubernetes-Networking: Der Überblick

Das OSI-Modell für Kubernetes-Networking ist eine der klarsten Methoden, um die oft komplexe Netzwerkrealität in Kubernetes verständlich zu strukturieren. Kubernetes abstrahiert viele Details: Pods bekommen IPs, Services wirken wie stabile Endpunkte, Ingress leitet Traffic „einfach“ weiter, und ein Service Mesh kann plötzlich mTLS, Retries oder Observability liefern. Gleichzeitig ist Networking in Kubernetes kein einzelnes Feature, sondern ein Zusammenspiel aus Linux-Netzwerkstack, Container-Netzwerk (CNI), Routing/Overlay-Techniken, Load Balancing, DNS und Anwendungsprotokollen. Genau hier hilft das OSI-Modell: Es trennt Symptome von Ursachen. Ein Timeout beim Aufruf einer API sieht nach Schicht 7 aus, kann aber durch MTU/Fragmentierung (Schicht 3), Paketverlust (Schicht 1–2), falsch gesetzte Ports (Schicht 4) oder TLS-Fehler (Schicht 6) entstehen. In diesem Überblick ordnen wir zentrale Kubernetes-Networking-Bausteine den OSI-Schichten zu, erklären typische Stolperfallen und zeigen, wie Sie den Stack systematisch lesen – unabhängig davon, ob Sie auf Bare Metal, in einer Managed Kubernetes-Umgebung oder hybrid arbeiten.

Table of Contents

Warum Kubernetes-Networking ohne OSI schnell unübersichtlich wird

Kubernetes verfolgt ein klares Netzwerkkonzept: Jeder Pod soll (in der Regel) eine eigene IP bekommen, Pods sollen untereinander ohne NAT erreichbar sein, und Services sollen stabile VIPs beziehungsweise virtuelle Endpunkte bereitstellen. In der Praxis kommen jedoch Schichten hinzu, die nicht sofort sichtbar sind: Overlay-Netze (VXLAN, Geneve), eBPF-Datenpfade, kube-proxy mit iptables oder IPVS, Cloud-Load-Balancer-Integrationen, Network Policies, Ingress Controller, Gateway APIs und Service-Mesh-Komponenten. Das OSI-Modell ist dabei kein „Schema aus dem Lehrbuch“, sondern ein Denkwerkzeug für Alltagssituationen:

Architekturverständnis: Welche Komponente arbeitet auf L3, welche auf L4 oder L7?
Schnelleres Troubleshooting: Erst Link/Reachability, dann Ports/Transport, dann TLS/HTTP.
Security-Design: NetworkPolicy (L3/L4) vs. WAF/Ingress-Regeln (L7) vs. mTLS (L6).
Performance: MTU, Encapsulation, Connection Tracking, Load-Balancer-Algorithmen, Retries.

Kubernetes-Grundbegriffe als Basis für das OSI-Mapping

Bevor wir die Schichten durchgehen, lohnt eine kurze Einordnung der wichtigsten Kubernetes-Networking-Begriffe:

Pod-Netzwerk (Pod CIDR): IP-Adressraum, aus dem Pods Adressen erhalten.
Service-Netzwerk (Service CIDR): Virtueller Adressraum für ClusterIP-Services.
CNI (Container Network Interface): Plugin-Schnittstelle, über die Kubernetes die Netzwerkanbindung von Pods realisiert.
kube-proxy: Implementiert Service-Weiterleitung (z. B. per iptables/IPVS) – oder wird durch eBPF-basierte Lösungen ersetzt.
Ingress/Gateway: Eintrittspunkt für HTTP/HTTPS (typischerweise L7) in den Cluster.
CoreDNS: DNS im Cluster; kritisch für Service Discovery.
NetworkPolicy: Regeln, die Verkehr zwischen Pods/Namespaces steuern (abhängig vom CNI).

Eine verlässliche Referenz für das Basiskonzept (Pods, Services, DNS, Ingress) ist die Kubernetes-Dokumentation zu Services und Networking.

Schicht 1: Physical – Knoten, NICs und die reale Infrastruktur

Auch wenn Kubernetes „cloud-native“ wirkt: Am Ende laufen Pods auf Nodes, und Nodes hängen an echter Hardware oder virtueller Infrastruktur. Schicht 1 umfasst Signale, Kabel, Funk (WLAN), physische Switchports, aber auch virtuelle NICs und Hypervisor-Backends in Cloud-Umgebungen. Kubernetes selbst steuert diese Ebene nicht, dennoch beeinflusst sie den Cluster massiv.

Typische Ursachen: Defekte Kabel/Ports, instabile Links, fehlerhafte Treiber, CPU-Steal/Noisy Neighbors (virtuell), fehlerhafte SR-IOV-Konfigurationen.
Typische Symptome: Sporadischer Paketverlust, Latenzspitzen, Verbindungsabbrüche, Pods „flappen“ bei Node-Problemen.
Praxis-Hinweis: Wenn mehrere Services gleichzeitig Timeouts zeigen, lohnt der Blick auf Node-Netzwerk und Underlay, bevor man „die App“ verdächtigt.

Schicht 2: Data Link – Switching, MAC, VLAN und Overlays

Auf Schicht 2 geht es um Frames, MAC-Adressen und Switching. In klassischen Rechenzentren spielen VLANs und L2-Domänen eine große Rolle; in Kubernetes-Setups hängt das stark vom CNI und der Umgebung ab. In der Cloud ist L2 meist abstrahiert, auf Bare Metal kann L2 sehr präsent sein. Overlays wie VXLAN kapseln L2/L3-Verkehr, um Pod-Netze über Node-Netze zu transportieren.

Wie Schicht 2 in Kubernetes sichtbar wird

Overlay-Encapsulation: VXLAN/Geneve erzeugen zusätzliche Header und beeinflussen MTU sowie Fragmentierung.
Broadcast/ARP/ND: Abhängig vom Design können ARP/Neighbor Discovery relevant sein, z. B. bei bestimmten Load-Balancer- oder Bare-Metal-Szenarien.
VLAN-Segmentierung: Häufig außerhalb von Kubernetes konfiguriert (Switching/Top-of-Rack), aber entscheidend für Reachability.

Schicht 3: Network – IP, Routing, Pod CIDR, Service CIDR, MTU

Schicht 3 ist das Herzstück von Kubernetes-Networking. Pods erhalten IP-Adressen, Traffic wird geroutet (nativ oder per Overlay), und Policies sowie Observability-Tools setzen oft auf L3-Informationen. Der Cluster besteht praktisch aus mehreren IP-Domänen: Node-Netz, Pod-Netz, Service-Netz und ggf. zusätzliche Netze (z. B. für Storage oder Management).

CNI-Plugins und das L3-Modell

Das CNI-Plugin entscheidet, wie Pod-IP-Adressen vergeben werden und wie Pakete zwischen Pods und Nodes fließen. Es gibt grob zwei Ansätze:

Routable / Underlay-nah: Pod-Netze werden geroutet (z. B. via BGP oder Cloud-Routing). Vorteil: weniger Overhead, oft bessere Performance und MTU-Sicherheit.
Overlay: Pod-Traffic wird gekapselt (z. B. VXLAN). Vorteil: einfache Skalierung über L3-Underlays hinweg; Nachteil: Encapsulation-Overhead, MTU-Management wird wichtiger.

Zur CNI-Schnittstelle selbst ist die CNI-Projektseite eine gute Einstiegsquelle, um zu verstehen, welche Aufgaben ein Plugin übernimmt.

IP-Planung: Wie viele Adressen liefert ein CIDR wirklich?

Gerade in großen Clustern ist IP-Exhaustion ein häufiger Grund für rätselhafte Deploy-Fehler oder Pending-Pods. Eine schnelle Orientierung bietet die Adressanzahl eines IPv4-/n-Netzes:

$Adressen = 2^{32 - n}$

In der Praxis reservieren Plattformen und CNIs häufig Adressen (z. B. pro Node, pro Subnetz oder für Systemkomponenten). Deshalb ist es sinnvoll, Pod CIDR und Service CIDR großzügig zu dimensionieren – insbesondere, wenn Autoscaling, viele Namespaces oder dichte Node-Pools geplant sind.

MTU und Fragmentierung als typischer Kubernetes-Schmerzpunkt

MTU-Probleme wirken oft „mystisch“: Große Antworten brechen ab, TLS-Handshakes hängen, gRPC-Streams sind instabil. In Kubernetes entstehen MTU-Mismatches besonders häufig durch Overlay-Encapsulation, Cloud-Transportnetze und VPNs. Die Faustregel: Je mehr Kapselung, desto sorgfältiger muss die effektive MTU entlang der gesamten Kette abgestimmt sein.

Schicht 4: Transport – TCP/UDP, kube-proxy, Service Load Balancing

Auf Schicht 4 entscheidet sich, ob Verbindungen zustande kommen, stabil bleiben und sinnvoll verteilt werden. Kubernetes Services sind konzeptionell L4-Objekte: Sie bieten eine virtuelle IP (ClusterIP) und verteilen Traffic auf Endpoints (Pods). Die konkrete Umsetzung erfolgt durch kube-proxy (iptables/IPVS) oder durch eBPF-basierte Datenpfade in modernen CNIs.

Wie Services auf L4 funktionieren

ClusterIP: Virtuelle IP innerhalb des Clusters; Weiterleitung auf Pod-Endpunkte.
NodePort: Öffnet einen Port auf jedem Node und leitet zum Service weiter.
LoadBalancer: In Cloud-Umgebungen oft Integration mit einem externen Load Balancer; intern weiterhin Service-Logik.

iptables, IPVS und eBPF: warum das OSI-Mapping praktisch hilft

iptables-Modus: Service-Weiterleitung über Regeln und NAT/Weiterleitung im Kernel; Debugging oft über Regelketten und Connection Tracking.
IPVS-Modus: Kernel-Load-Balancer, häufig effizienter bei vielen Services/Endpoints.
eBPF-Datenpfad: Kann kube-proxy ersetzen oder ergänzen; bietet oft bessere Observability und Performance, verschiebt aber Debugging-Methoden.

Wer tiefer einsteigen möchte, findet in der offiziellen Kubernetes-Dokumentation zu Services die wichtigsten Grundlagen zu Service-Typen und Endpoints.

Schicht 5: Session – Zustände, Sticky Sessions, gRPC und Verbindungslebenszyklen

Die Session-Schicht ist in Kubernetes weniger als „separates Protokoll“ sichtbar, aber operativ sehr relevant. Viele moderne Anwendungen nutzen langlebige Verbindungen (WebSockets), Streams (gRPC) oder wiederverwendete HTTP/2-Verbindungen. Dadurch werden Themen wie Connection Reuse, Idle Timeouts, Session Affinity und Retry-Strategien entscheidend – und sie beeinflussen, wie ein Problem wahrgenommen wird.

Session Affinity: Ein Service kann (je nach Modus) versuchen, Clients an denselben Endpoint zu binden. Das kann Stabilität erhöhen, aber Lastverteilung verzerren.
Idle Timeouts: Load Balancer und Proxies können inaktive Verbindungen schließen; Anwendungen interpretieren das als „sporadische Disconnects“.
gRPC/HTTP2: Wenige Verbindungen tragen viel Traffic; ein einzelnes Timeout wirkt dann wie ein großflächiger Ausfall.

Schicht 6: Presentation – TLS/mTLS, Zertifikate, Kompression, Encoding

In Kubernetes begegnen Sie Schicht 6 fast überall: HTTPS am Ingress, TLS zu Datenbanken, mTLS im Service Mesh, Zertifikatsrotation, SNI, Cipher Policies. Gleichzeitig betrifft Schicht 6 auch Datenrepräsentation: JSON vs. Protobuf, Kompression (gzip/Brotli), Zeichenkodierung. In der Praxis werden TLS-Themen besonders dann sichtbar, wenn Komponenten TLS terminieren oder „durchreichen“.

TLS-Terminierung im Cluster

Am Ingress Controller: TLS endet am Ingress, danach ist Traffic intern ggf. unverschlüsselt oder erneut verschlüsselt.
End-to-End TLS: TLS wird bis zum Pod durchgereicht; Proxies müssen SNI/ALPN korrekt handhaben.
mTLS zwischen Services: Häufig über Service Mesh; erhöht Sicherheit, kann aber Debugging komplexer machen.

Für das offizielle Kubernetes-Konzept rund um Ingress und dessen Rolle als Eintrittspunkt ist die Ingress-Dokumentation hilfreich, insbesondere im Zusammenspiel mit TLS.

Schicht 7: Application – Ingress, Gateway API, DNS, HTTP und Service Mesh

Auf Schicht 7 findet das statt, was Nutzer direkt erleben: HTTP-Statuscodes, API-Routing, Authentifizierung, Caching, Rate Limits und Observability. In Kubernetes bündeln sich L7-Funktionen in Ingress Controllern, API Gateways, der Gateway API, Service-Mesh-Proxies und häufig auch in externen Komponenten wie WAFs oder CDNs.

Ingress und Gateway API im OSI-Kontext

Ingress: Klassisch ein L7-Router für HTTP/HTTPS; verteilt Traffic anhand von Hostname und Pfad.
Gateway API: Modernerer Ansatz zur Modellierung von L4- und L7-Gateways; bietet oft klarere Rollen und Erweiterbarkeit.
Service Mesh: Fügt L7-Features (Routing, Retries, Telemetrie) und mTLS hinzu, wirkt aber auch auf L4 (Connection Handling) und L6 (TLS).

Wenn Sie Service Mesh evaluieren, ist es sinnvoll, nicht nur „Features“ zu vergleichen, sondern die Schichten zu betrachten: Was passiert mit TLS? Wo werden Retries gesetzt? Wie werden Timeouts definiert? Eine gute Einstiegsperspektive liefert die Istio-Konzepteinführung, weil sie die Wirkmechanik von Proxies und Policies gut erklärt.

DNS in Kubernetes: CoreDNS als L7-Kritikalität

DNS ist ein Anwendungsprotokoll (Schicht 7), wird in Kubernetes aber wie ein Grundnahrungsmittel behandelt: Fällt DNS aus oder ist es langsam, wirkt „alles kaputt“. Services werden per Namen aufgelöst, viele Bibliotheken und Sidecars hängen an DNS, und Caching/TTL-Verhalten beeinflusst Rollouts und Failover.

Typische Symptome: Pods können Services nicht finden, sporadische Verbindungsfehler, lange Startzeiten.
Typische Ursachen: Überlasteter DNS, zu aggressive Retries, NetworkPolicy blockiert DNS-Traffic, fehlerhafte Upstream-Resolver.
OSI-Lernpunkt: DNS-Fehler sehen wie „Netzwerk“ aus, sind aber häufig ein L7-Thema mit L3/L4-Nebenwirkungen.

NetworkPolicy und Security: welche OSI-Schichten werden wirklich kontrolliert?

NetworkPolicy wird oft als „Firewall von Kubernetes“ bezeichnet. Das ist nur teilweise richtig. NetworkPolicies steuern in den meisten Implementierungen vor allem Verkehr auf Schicht 3 und 4: Quell-/Ziel-Pods (IP/Labels), Ports und Protokolle. L7-Regeln (z. B. „nur GET auf /health“) sind nicht Teil der Standard-NetworkPolicy und erfordern zusätzliche Technologien (z. B. L7-Proxies, Service Mesh oder spezialisierte Policy Engines).

L3/L4: Allow/Deny zwischen Namespaces/Pods, Portfreigaben, Protokolle.
L7 (optional, technologieabhängig): HTTP-Methoden, Pfade, Header – meist über Proxy/Mesh oder spezielle Erweiterungen.
Praktischer Effekt: NetworkPolicy löst viele Ost-West-Security-Anforderungen, ersetzt aber kein L7-Access-Control-Design.

Typische Fehlerbilder im Kubernetes-Networking – sortiert nach OSI-Schichten

Der größte Nutzen des OSI-Modells entsteht, wenn Sie Symptome schnell einer Schichtfamilie zuordnen. Das reduziert „Blind Debugging“ und vermeidet, dass man zu früh an Ingress oder Code schraubt, obwohl ein Routing- oder MTU-Problem vorliegt.

Schicht 1–2: Link- und Underlay-Probleme

Intermittierende Paketverluste, die sich als Retransmits/Timeouts äußern
Nur einzelne Nodes betroffen (Pod-zu-Pod-Fehler korrelieren mit einem Node)
Plötzliche Latenzspitzen bei ansonsten unverändertem Deployment

Schicht 3: Routing, IP-Planung, MTU

Pods bleiben Pending oder bekommen keine IP (Adressraum erschöpft, CNI-Probleme)
Verbindungen funktionieren nur in eine Richtung (asymmetrisches Routing, falsche Routen)
Große Antworten brechen ab (MTU/Fragmentierung, Overlay-Overhead)

Schicht 4: Ports, Services, Load Balancing

Service erreichbar, aber nur sporadisch erfolgreich (Endpoint-Flapping, Health Checks, Conntrack)
Timeouts unter Last (Connection Limits, NAT/Conntrack-Exhaustion, ungünstige LB-Settings)
Unterschiedliche Ergebnisse je Client (Session Affinity, L4-Verteilung)

Schicht 6–7: TLS, HTTP, DNS, Ingress/Mesh

TLS-Handshakes schlagen fehl (Zertifikate, SNI, Chain, Zeitdrift)
HTTP-Fehler wie 404/503/502 (Routing-Regeln, Upstream-Health, Mesh-Policies)
„Service nicht gefunden“ oder langsame Auflösung (DNS, Policy blockiert UDP/TCP 53)

OSI-orientierte Checkliste für den Kubernetes-Alltag

Diese Checkliste ist bewusst schichtbasiert formuliert, damit Sie unabhängig von CNI, Cloud oder On-Prem konsistent vorgehen können. Sie eignet sich für Einsteiger, bleibt aber auch in komplexen Umgebungen (Multi-Cluster, Hybrid, Mesh) ein zuverlässiges Raster.

Schicht 1–2: Sind die betroffenen Nodes gesund? Gibt es auffällige Latenz/Paketverlust? Tritt das Problem nur auf bestimmten Nodes auf?
Schicht 3: Sind Pod CIDR und Service CIDR korrekt dimensioniert? Gibt es MTU-Overhead durch Overlay? Stimmen Routes/Peering/Firewall-Regeln außerhalb des Clusters?
Schicht 4: Stimmen Ports und Protokolle? Zeigen Services die erwarteten Endpoints? Gibt es Timeouts/Conntrack-Probleme unter Last?
Schicht 6: Ist TLS korrekt terminiert oder durchgereicht? Sind Zertifikate gültig und aktuell? Greift mTLS und wenn ja, wo?
Schicht 7: Löst DNS zuverlässig auf? Stimmen Ingress/Gateway-Regeln (Host/Path)? Gibt es Policies, Rate Limits oder WAF-Regeln, die Requests blockieren?

Outbound-Ressourcen für vertiefendes Lernen

Für ein solides, belastbares Verständnis (und für saubere Dokumentation im Team) sind primäre Quellen besonders wertvoll. Die folgenden Ressourcen sind praxisnah und erklären die Konzepte, die im OSI-Modell-Mapping immer wieder auftauchen:

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.