Kubernetes Networking für Einsteiger: Pod, Service, Ingress (Grafik + OSI-Mapping)

Kubernetes Networking wirkt auf Einsteiger oft wie ein „magischer“ Bereich: Pods bekommen IPs, Services verteilen Traffic, und ein Ingress bringt alles nach außen – scheinbar ohne dass man klassische Netzwerkgeräte sieht. Genau deshalb ist Kubernetes Networking so wichtig zu verstehen: In einem Cluster entstehen mehrere virtuelle Netzebenen übereinander, und jedes Problem (Timeouts, 502, „Service nicht erreichbar“) lässt sich schneller lösen, wenn man weiß, wo Pod, Service und Ingress im Datenpfad liegen. Dieser Leitfaden erklärt praxisnah, wie das Netzwerkmodell von Kubernetes aufgebaut ist, welche Aufgabe Pod-IP, Service-IP und Ingress übernehmen und welche Komponenten im Hintergrund arbeiten (CNI, kube-proxy, DNS, Ingress Controller). Zusätzlich erhalten Sie eine kompakte Grafik und ein OSI-Mapping, damit Sie Netzwerkfehler systematisch einordnen können: Ist es Layer 3/4 (Routing, Ports), Layer 7 (HTTP, Host Header) oder eher Service Discovery (DNS)? Ziel ist ein stabiles Grundverständnis, das Sie in jedem Kubernetes-Setup anwenden können – ob in Managed Kubernetes (EKS, GKE, AKS) oder On-Prem.

Grafik: Pod, Service und Ingress im Datenpfad

Die folgende Grafik zeigt den typischen Weg einer HTTP-Anfrage von außen bis zu einem Pod. Sie ist bewusst generisch gehalten, weil sich Details je nach Cloud, Ingress Controller und CNI Plugin unterscheiden, das Grundprinzip aber gleich bleibt.

Das Kubernetes-Netzwerkmodell: Die drei Grundregeln

Kubernetes verfolgt ein klares Netzwerkmodell, das unabhängig vom Cloud-Provider funktionieren soll. Für Einsteiger sind drei Regeln entscheidend, weil sie viele „Warum geht das nicht?“-Fragen beantworten.

• Jeder Pod hat eine eigene IP: Ein Pod ist im Netzwerk wie ein eigenständiger Host. Container im Pod teilen sich die Pod-IP und unterscheiden sich über Ports.
• Pods können ohne NAT miteinander sprechen: In der Idealvorstellung kann Pod A direkt Pod B erreichen (Pod-IP zu Pod-IP), auch wenn sie auf unterschiedlichen Nodes laufen.
• Services geben stabile Endpunkte: Pods sind dynamisch (kommen/gehen). Ein Service stellt eine stabile virtuelle IP/DNS-Adresse bereit und leitet an aktuelle Pods (Endpoints) weiter.

Die Umsetzung dieser Regeln hängt vom CNI Plugin ab (Container Network Interface). Das CNI sorgt dafür, dass Pods IPs bekommen, Routen gesetzt werden und Pod-zu-Pod-Traffic zwischen Nodes funktioniert. Bekannte CNIs sind z. B. Calico, Cilium, Flannel oder cloud-spezifische Implementierungen.

Pod-Netzwerk für Einsteiger: Pod-IP, Ports und Kommunikation

Ein Pod ist die kleinste deploybare Einheit in Kubernetes und enthält einen oder mehrere Container. Aus Sicht des Netzwerks ist wichtig: Alle Container im Pod teilen sich denselben Netzwerk-Namespace. Das bedeutet, sie teilen sich die Pod-IP und den Portraum. Zwei Container im selben Pod können sich daher über localhost erreichen (z. B. App → Sidecar), während Kommunikation zu anderen Pods über Pod-IP oder (besser) über Services erfolgt.

• Pod-IP: Wird vom CNI vergeben und ist innerhalb des Clusters routbar.
• ContainerPorts: Sind dokumentativ/konfigurationsnah, aber entscheidend ist, welche Ports der Prozess wirklich bindet.
• Node-zu-Pod-Pfade: Pods laufen auf Nodes; das CNI sorgt für virtuelle Interfaces (veth), Bridges oder eBPF-basierte Weiterleitung.

Typische Pod-Connectivity-Probleme

• Der Pod läuft, aber die App lauscht nur auf 127.0.0.1 statt auf 0.0.0.0.
• NetworkPolicies blockieren Traffic zwischen Namespaces oder Labels.
• DNS-Auflösung funktioniert nicht (CoreDNS down, falsche DNS-Policy im Pod).
• MTU-Probleme in Overlays/VXLAN führen zu „klein geht, groß bricht“ (Fragmentierung, Drops).

Services verstehen: ClusterIP, NodePort und LoadBalancer

Ein Kubernetes Service ist eine Abstraktion, die eine Gruppe von Pods als ein Ziel darstellt. Der Service selektiert Pods typischerweise über Labels (Selector) und kennt die zugehörigen Endpoints (heute meist über EndpointSlice). Für Clients im Cluster bedeutet das: Sie sprechen den Service an und Kubernetes verteilt den Traffic auf passende Pods. Der Service ist also ein zentraler Baustein für Service Discovery und Load Balancing innerhalb des Clusters.

• ClusterIP: Standardtyp. Eine virtuelle IP ist nur im Cluster erreichbar. Ideal für interne Kommunikation.
• NodePort: Öffnet einen Port auf jedem Node. Externer Traffic kann NodeIP:NodePort erreichen und wird zum Service weitergeleitet. Einfach, aber weniger elegant.
• LoadBalancer: In Clouds wird ein externer (oder interner) Load Balancer provisioniert, der Traffic zum Service bringt. Häufig der Standardweg für externe Erreichbarkeit ohne Ingress.
• Headless Service: Ohne ClusterIP. DNS liefert direkt Pod-IPs (wichtig für StatefulSets und direkte Endpunktsteuerung).

Was macht kube-proxy eigentlich?

Damit eine ClusterIP „virtuell“ funktioniert, muss irgendwo entschieden werden, zu welchem Pod weitergeleitet wird. Das erledigt typischerweise kube-proxy auf den Nodes, indem er Regeln über iptables oder IPVS verwaltet. Moderne Setups können auch eBPF-basierte Datenpfade nutzen, die kube-proxy teilweise ersetzen oder ergänzen. Für Einsteiger reicht die Merkhilfe: Service-IP ist virtuell, und eine Node-Komponente sorgt für das Weiterleiten zu realen Pod-IPs.

DNS und Service Discovery: Warum Namen wichtiger sind als IPs

In Kubernetes sollten Sie nahezu nie direkt auf Pod-IPs „bauen“, weil Pods dynamisch sind. Stattdessen nutzt man DNS-Namen, die in der Regel von CoreDNS bereitgestellt werden. Ein Service bekommt automatisch einen DNS-Eintrag wie meinservice.meinnamespace.svc.cluster.local (abhängig von Cluster-Domain). Anwendungen verbinden sich über diesen Namen und profitieren davon, dass Kubernetes intern die aktuellen Endpunkte kennt.

• Service-DNS: Stabile Namen → stabile Verbindungen, auch wenn Pods ersetzt werden.
• Headless + Stateful: DNS kann einzelne Pod-Namen liefern, z. B. für Replikationscluster.
• Externe Namen: Über ExternalName oder zusätzliche DNS-Konfigurationen lassen sich externe Abhängigkeiten sauber abbilden.

Praktischer Tipp: DNS-Fehler sehen oft aus wie Netzwerkfehler

Wenn Anwendungen „Timeout“ melden, kann die Ursache auch sein, dass der Name nicht aufgelöst wird oder in einen falschen Endpunkt zeigt. In Observability sollten DNS-Lookup-Zeiten und Fehler (NXDOMAIN, SERVFAIL) sichtbar sein, um OSI-Layer sauber einzuordnen.

Ingress für Einsteiger: HTTP-Routing als Layer-7-Einstiegspunkt

Ingress ist eine Kubernetes-API-Ressource, die Regeln für HTTP/HTTPS-Routing beschreibt. Ein Ingress allein „macht“ jedoch noch nichts: Er benötigt einen Ingress Controller, der diese Regeln umsetzt (z. B. NGINX Ingress, HAProxy, Traefik oder cloud-native Controller). Der typische Nutzen: Sie erhalten einen zentralen Einstiegspunkt, der anhand von Hostnames und Pfaden (z. B. /api, /shop) an unterschiedliche Services weiterleitet. Das ist besonders wertvoll, wenn Sie viele Services über eine oder wenige externe IPs bereitstellen möchten.

• Host-basiertes Routing: api.example.com → Service A, shop.example.com → Service B.
• Pfad-basiertes Routing: /v1 → Service A, /v2 → Service B.
• TLS-Termination: Der Ingress Controller kann TLS beenden und Zertifikate verwalten (häufig via cert-manager).
• Zentrale Policies: Rate Limiting, Auth, WAF-Integration oder Security Headers lassen sich am Ingress bündeln (je nach Controller).

Ingress vs. Service LoadBalancer: Wann welches Modell?

• Service LoadBalancer ist einfach und direkt: ein Load Balancer pro Service (oder pro „Frontdoor“-Service). Gut für wenige Services oder klare Trennung.
• Ingress skaliert für viele HTTP(S)-Services: ein zentraler Einstiegspunkt, mehrere Backends. Gut für Plattformen mit vielen Routen und Domains.
• Für Nicht-HTTP (z. B. reine TCP/UDP-Workloads) sind Ingress-Lösungen abhängig vom Controller; häufig ist ein LoadBalancer-Service oder ein Gateway-Ansatz passender.

OSI-Mapping: Wo Pod, Service und Ingress im Modell liegen

Das OSI-Modell hilft, Kubernetes Networking systematisch zu verstehen. Wichtig ist: Kubernetes abstrahiert, aber es verschwindet nicht. Pod-zu-Pod ist primär Layer 3/4, Services sind eine virtuelle Layer-4-Abstraktion, und Ingress ist klassisch Layer 7 (HTTP). Zusätzlich wirken DNS (Layer 7 aus Sicht der Anwendung) und TLS (Layer 6/7 je nach Betrachtung) stark auf das Verhalten.

• Layer 2 (Sicherung): Innerhalb eines Nodes virtuelle Interfaces/Bridges; zwischen Nodes hängt es von Cloud/VPC oder Overlay ab.
• Layer 3 (Netzwerk): Pod-IP-Routing, Subnetze der Nodes, Overlay-Netze, Peering/Routes in der Cloud.
• Layer 4 (Transport): TCP/UDP-Ports, Services als virtuelle L4-Ziele, kube-proxy/ipvs/iptables oder eBPF-Pfade.
• Layer 5/6 (Session/Presentation): TLS-Handshake, Zertifikate, mTLS im Mesh, SNI, Cipher Suites.
• Layer 7 (Anwendung): HTTP-Host Header, Pfade, Ingress-Routing, Auth, Cookies, gRPC/HTTP2.

Fehlerbilder nach OSI: Schnelle Einordnung

• „Connection refused“: Meist Layer 4/7 (Port offen? Prozess lauscht? falscher TargetPort?).
• „Timeout“: Häufig Layer 3/4 (Routing/Policy/Drop) oder DNS (Name nicht auflösbar, falsches Ziel).
• „502/503 am Ingress“: Meist Layer 7 (Upstream nicht erreichbar, Health Checks, falsche Service-Ports, TLS zum Backend).
• „TLS handshake failed“: Layer 6/7 (Zertifikat, SNI, Protokollversion, mTLS-Policy).

Der komplette Datenpfad: Von außen zum Pod in klaren Schritten

Wenn Sie den Datenpfad als Kette verstehen, können Sie gezielt messen und debuggen. Ein typischer HTTP-Request läuft (vereinfacht) so ab:

• Client löst DNS auf und erreicht eine externe IP (z. B. Cloud Load Balancer vor dem Ingress Controller).
• Traffic landet beim Ingress Controller, der anhand von Host/Path eine Regel wählt.
• Ingress leitet an einen Kubernetes Service (ClusterIP) weiter.
• Der Service verteilt auf einen passenden Pod (Endpoint/EndpointSlice) und wählt Port/TargetPort.
• Der Pod empfängt den Traffic auf dem Container-Port; die Anwendung antwortet.

Zusatzschichten sind häufig: TLS-Termination am Ingress, mTLS im Service Mesh, Egress-Proxies, NetworkPolicies, sowie cloud-spezifische Datenpfade (z. B. interne Load Balancer oder Node Security Groups).

NetworkPolicy als Segmentierung: „Default Deny“ richtig einführen

Kubernetes NetworkPolicies ermöglichen das Steuern von Pod-zu-Pod-Traffic auf Basis von Labels und Namespaces. Einsteiger sollten wissen: NetworkPolicies wirken nur, wenn das CNI Plugin sie unterstützt. In vielen Umgebungen ist das der Fall, aber nicht automatisch. Ein praktikabler Weg ist, zunächst Sichtbarkeit aufzubauen (Flow Logs, Policy-Logs, Metriken) und dann schrittweise restriktiver zu werden.

• Start: Dokumentieren, welche Services miteinander sprechen müssen (Dependency Map).
• Baseline: „Allow DNS“ und notwendige Plattformservices (z. B. Monitoring/Logging) definieren.
• Default Deny: Pro Namespace oder pro kritischen Bereich einführen, aber mit Canary und klaren Rollback-Schritten.
• Label-Disziplin: Policies sind nur so gut wie stabile Labels (App, Tier, Owner, Environment).

Debugging-Checkliste für Einsteiger: Pod, Service, Ingress systematisch prüfen

Wenn etwas nicht erreichbar ist, hilft eine feste Reihenfolge. Damit vermeiden Sie „blindes Herumprobieren“ und finden schneller den Layer, der tatsächlich bricht.

• Pod-Ebene: Läuft der Pod? Ist Readiness/Health grün? Lauscht die App auf dem erwarteten Port?
• Service-Ebene: Stimmen Selector-Labels? Gibt es Endpoints/EndpointSlices? Ist der Port korrekt gemappt (port/targetPort)?
• DNS: Lässt sich der Service-Name auflösen? Zeigt er auf den richtigen Service? Gibt es DNS-Fehler?
• NetworkPolicy/Security: Blockiert eine Policy den Pfad? Sind Namespace- oder PodSelector korrekt?
• Ingress-Ebene: Treffen Host/Path-Regeln zu? Ist TLS korrekt? Zeigt das Backend auf den richtigen Service/Port?
• Cloud/Edge: Falls ein externer LB beteiligt ist: Health Checks, Security Groups/Firewall-Regeln, interne/externe IP-Scopes.

Merksatz: Erst „Name → Service → Pod“, dann „Ingress → Service → Pod“

Wenn der interne Service-Pfad nicht funktioniert, wird der Ingress-Pfad fast immer auch scheitern. Deshalb lohnt es sich, zunächst interne Erreichbarkeit zu sichern (Service Discovery, Endpoints, Policies), bevor man am Ingress Controller „herumdreht“.

Wichtige Begriffe, die Sie einmal sauber verankern sollten

• CNI: Plugin-Schnittstelle, die Pod-Netzwerk bereitstellt (IPs, Routen, Policies).
• kube-proxy: Komponente, die Service-VIPs und Load Balancing auf Node-Ebene umsetzt (iptables/IPVS oder alternative Datenpfade).
• CoreDNS: DNS im Cluster für Service Discovery und interne Namensauflösung.
• EndpointSlice: Moderne Darstellung der Service-Endpunkte, skaliert besser als alte Endpoints-Objekte.
• Ingress Controller: Implementiert Ingress-Regeln; ohne Controller ist Ingress nur Konfiguration.

Outbound-Links zu relevanten Informationsquellen

• Kubernetes Services, Networking und grundlegende Konzepte
• Kubernetes Service: ClusterIP, NodePort, LoadBalancer und Headless
• Kubernetes Ingress: Routing, TLS und Controller-Prinzip
• Kubernetes NetworkPolicies: Segmentierung und Traffic-Kontrolle
• CNI-Spezifikation: Container Network Interface Grundlagen
• Kubernetes DNS und CoreDNS: Namensauflösung im Cluster

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.