Service vs. Ingress: Der oft verwirrende Traffic-Pfad ist eines der Themen, die in Kubernetes immer wieder für Missverständnisse sorgen – selbst in Teams mit viel Plattform-Erfahrung. Der Grund ist simpel: „Service“ und „Ingress“ lösen unterschiedliche Probleme auf unterschiedlichen Ebenen, sehen in YAML aber ähnlich „zugänglich“ aus. In der Praxis führt das zu typischen Fragen wie: „Warum erreiche ich meine Anwendung über die Service-IP, aber nicht über die Domain?“, „Warum sehe ich im Pod-Log die falsche Client-IP?“, „Warum funktioniert der Ingress, aber Healthchecks scheitern?“ oder „Warum blockiert die NetworkPolicy nur, wenn ich über Ingress gehe?“ Um den oft verwirrenden Traffic-Pfad zu verstehen, müssen Sie die Rollen sauber trennen: Ein Kubernetes Service ist primär ein Layer-4-Konstrukt für stabile virtuelle Endpunkte und Lastverteilung zu Pods. Ein Ingress ist primär ein Layer-7-Konstrukt für HTTP/HTTPS-Routing nach Hostname und Pfad – und er funktioniert nur mit einem Ingress Controller, der tatsächlich Traffic entgegennimmt und weiterleitet. Sobald Sie diese Trennung im Kopf haben, werden Fehlerbilder deutlich einfacher: Sie können prüfen, ob das Problem in der Service-Weiterleitung, im Ingress-Routing, in DNS/TLS, in Healthchecks oder in den dahinterliegenden Endpoints liegt.
Begriffsabgrenzung: Was ein Service ist – und was nicht
Ein Kubernetes Service bietet einen stabilen Netzwerkendpunkt für eine dynamische Menge an Pods. Pods können sich ändern (Reschedules, Rolling Updates), aber der Service bleibt als konstante Adresse erhalten. Der Service löst damit das Problem der Service Discovery und der Lastverteilung auf Netzwerkebene: Clients sprechen den Service an, Kubernetes leitet an passende Pod-Endpunkte (Endpoints/EndpointSlices) weiter. Ein Service ist dabei kein „Proxy“ im klassischen Sinne, sondern ein Abbildungsmechanismus, der häufig über iptables/IPVS (kube-proxy) oder eBPF (je nach CNI) umgesetzt wird.
- Service = stabiler virtueller Endpunkt (ClusterIP/NodePort/LoadBalancer) für Pods
- Routing-Kriterium ist meist Ziel-IP/Zielport (Layer 4), nicht Hostname/Pfad
- Abhängigkeit von Endpoints: ohne passende Pod-Selektoren gibt es keine Backends
Offizielle Grundlagen: Kubernetes Services.
Begriffsabgrenzung: Was Ingress ist – und warum es ohne Controller nicht existiert
Ingress beschreibt Regeln, wie HTTP/HTTPS-Anfragen in den Cluster geleitet werden sollen: basierend auf Hostnames (z. B. app.example.com), Pfaden (z. B. /api) und optional TLS. Entscheidend: Ingress ist nur die deklarative Regel. Die eigentliche Arbeit macht ein Ingress Controller (z. B. NGINX Ingress, HAProxy Ingress, Traefik, cloud-native Controller). Ohne Controller wird kein Traffic verarbeitet, selbst wenn das Ingress-Objekt korrekt aussieht.
- Ingress = HTTP/HTTPS-Routing-Regeln (Layer 7)
- Ingress Controller nimmt Traffic an und leitet weiter
- Backend ist fast immer ein Service, nicht direkt ein Pod
Offizielle Grundlagen: Kubernetes Ingress.
Der Kernunterschied im Alltag: Layer 4 vs. Layer 7
Der sicherste mentale Anker ist die Schichtlogik: Services sind primär Layer 4 (TCP/UDP), Ingress ist primär Layer 7 (HTTP/HTTPS). Ein Service kann nicht „nach URL-Pfad“ routen. Ein Ingress kann dagegen sehr wohl /api zu Service A und /ui zu Service B routen, weil er HTTP versteht. Umgekehrt ist ein Ingress nicht dafür gedacht, beliebige TCP-Protokolle zu verteilen (Datenbanken, MQTT, SMTP) – dafür nutzen Teams eher Services vom Typ LoadBalancer, spezielle Gateways oder separate L4-Load-Balancer.
Merksätze, die viele Debugging-Stunden sparen
- Wenn es nicht HTTP/HTTPS ist, ist Ingress meist nicht das richtige Werkzeug.
- Wenn es um stabile Pod-Erreichbarkeit im Cluster geht, ist der Service die Basis.
- Ingress „endet“ fast immer in einem Service; der Service „endet“ in Pods.
Der typische Traffic-Pfad Schritt für Schritt
Der oft verwirrende Traffic-Pfad entsteht, weil Ingress und Service hintereinander liegen und zusätzliche Komponenten dazwischen kommen: DNS, Load Balancer, NodePort, kube-proxy/eBPF, Endpoints, NetworkPolicies, TLS-Termination. Ein sauberes Debugging folgt dem Pfad in dieser Reihenfolge.
Pfad 1: Interner Client im Cluster zum Service
- Client-Pod ruft Service-DNS oder ClusterIP auf
- CoreDNS löst Service-Namen zu ClusterIP auf
- Service-Implementation (iptables/IPVS/eBPF) leitet an Endpoints weiter
- Ziel-Pod empfängt Traffic auf Pod-IP/Port
Wenn dieser Pfad scheitert, ist das Problem sehr häufig in Endpoints (falscher Selector), Ports (Service-Port vs. TargetPort), NetworkPolicy (Ingress/Egress), oder DNS (wenn über Namen gerufen wird).
Pfad 2: Externer Client über Ingress zur Anwendung
- Externer Client fragt DNS für app.example.com ab
- DNS zeigt auf eine externe IP (Load Balancer oder Node-IP)
- Load Balancer (Cloud oder extern) leitet Traffic an Ingress Controller
- Ingress Controller wendet Host-/Pfadregeln an, ggf. TLS-Termination
- Backend-Service wird angesprochen (ClusterIP)
- Service-Implementation leitet an Pod-Endpunkte weiter
- Ziel-Pod bekommt die Anfrage (ggf. mit geänderter Client-IP durch Proxying)
Hier sehen Sie: Ingress-Probleme können upstream (DNS, Zertifikat, LB), im Controller (Routing-Regeln, TLS, Annotationen) oder downstream (Service/Endpoints/NetworkPolicy) liegen. Genau diese Kette macht das Thema verwirrend, aber auch systematisch debuggbar.
Service-Typen: Warum ClusterIP, NodePort und LoadBalancer unterschiedliche Pfade erzeugen
Ein Service ist nicht immer „nur intern“. Der Typ definiert, wie er erreichbar ist und welche zusätzlichen Komponenten im Pfad auftauchen. Viele Ingress-Setups hängen an einem Service vom Typ NodePort oder LoadBalancer – und ändern dadurch das Verhalten bei Quell-IP, Healthchecks oder Firewall-Regeln.
- ClusterIP: nur innerhalb des Clusters erreichbar (Standard)
- NodePort: Service ist über einen Port auf jedem Node erreichbar (häufig als Anker für externe Load Balancer)
- LoadBalancer: Cloud- oder externer LB wird provisioniert, der auf den Service zeigt
Je nach Anbieter kann der LoadBalancer-Service direkt die Anwendung exponieren (ohne Ingress). In vielen produktiven Setups wird er jedoch genutzt, um den Ingress Controller erreichbar zu machen, der dann das Layer-7-Routing übernimmt.
Warum Ingress „manchmal“ wie ein Service wirkt
Ingress wirkt für viele wie „ein Service mit Domain“. Das liegt daran, dass der Ingress Controller oft selbst über einen Service erreichbar gemacht wird, häufig vom Typ LoadBalancer. Dann sehen Sie im Cluster einen „ingress-nginx-controller“ Service und denken: „Ingress = Service“. Tatsächlich ist dieser Service nur die Eintrittstür in den Controller. Die Routing-Entscheidung (Host/Pfad) passiert erst im Controller, nicht im Service.
Praktische Konsequenz
- Wenn der Ingress Controller-Service nicht erreichbar ist, hilft kein korrektes Ingress-Objekt.
- Wenn der Controller erreichbar ist, aber falsche Routen liefert, liegt es am Ingress-Objekt oder Controller-Konfiguration.
- Wenn Controller und Routing stimmen, aber Backends nicht erreichbar sind, liegt es am Service/Endpoints/Policies.
Häufige Fehlerbilder und ihre wahrscheinlichste Ursache entlang des Pfads
Der effizienteste Weg, Service vs. Ingress zu entwirren, ist eine Fehlerbild-zu-Pfad-Zuordnung. Sie sparen Zeit, wenn Sie Symptome nicht „global“ interpretieren, sondern dem wahrscheinlichsten Segment zuordnen.
„Service funktioniert, Ingress nicht“
- DNS zeigt auf falsche IP oder falschen Hostname
- TLS-Zertifikat/Secret fehlt oder passt nicht zum Host
- Ingress Controller ist nicht erreichbar (LB/Firewall/SecurityGroup)
- Ingress-Regeln matchen nicht (Host/Pfad), falscher IngressClass
„Ingress antwortet, aber Backend gibt 502/504“
- Backend-Service zeigt auf keine Endpoints (Selector/Labels)
- Service-Port/TargetPort falsch oder App lauscht nicht
- NetworkPolicy blockiert Ingress Controller → Backend (Egress/Ingress)
- Healthchecks/Readiness verhindern, dass Pods als Endpoints gelten
„Nur über Service-Name geht es nicht, über Pod-IP schon“
- DNS-Probleme (CoreDNS, NetworkPolicy zu UDP/TCP 53)
- Service-Definition falsch (Port-Mapping, Selector)
- Service-Routing-Mechanik (kube-proxy/eBPF) hat Konflikte oder Limits
„Client-IP ist im Pod-Log immer die Ingress-IP“
- TLS-/HTTP-Termination im Ingress Controller erzeugt neue Verbindung
- Source NAT durch Load Balancer oder NodePort-Pfad
- Fehlende/andere Header wie X-Forwarded-For (abhängig vom Controller)
NetworkPolicy und der verwirrende Pfad: Warum Policies „nur bei Ingress“ blockieren
NetworkPolicies greifen auf Pod-Ebene und steuern L3/L4-Flows. Wenn ein externer Client über Ingress kommt, ist der unmittelbare Quell-Pod aus Sicht des Backends nicht „der Client“, sondern der Ingress Controller (oder ein Gateway). Das verändert die notwendigen Allow-Regeln. Ein Backend, das Ingress-Traffic erlauben soll, muss daher Ingress vom Ingress-Controller-Pod (oder dessen Namespace/Labels) erlauben – nicht von „0.0.0.0/0“ und nicht von einem externen Client-Netz, das im Pod-Netzwerk gar nicht direkt sichtbar ist.
- Direkter Service-Call aus einem Pod: Quelle ist der Client-Pod
- Call über Ingress: Quelle ist oft der Ingress-Controller-Pod (bzw. dessen Pod-IP)
- Folge: Allow-Regeln müssen Ingress-Controller als legitime Quelle abbilden
Grundlagen zu NetworkPolicy: Kubernetes Network Policies.
Endpoints und EndpointSlices: Der unsichtbare Dreh- und Angelpunkt
Viele Probleme werden fälschlich Ingress oder Service zugeschrieben, sind aber eigentlich Endpoints-Probleme. Ein Service routet nur zu Pods, die vom Selector getroffen werden und als „bereit“ gelten. Wenn Labels nicht passen oder Pods nicht Ready sind, hat der Service keine Backends. Der Ingress Controller kann dann korrekt konfiguriert sein und dennoch 502/504 liefern, weil er downstream keinen erreichbaren Endpunkt hat.
- Selector-Mismatch: Service wählt falsche Pods oder keine Pods
- Readiness: Pods existieren, sind aber nicht bereit, daher keine Endpoints
- Port-Mismatch: Service-Port zeigt auf falschen TargetPort
Wenn Sie „Service vs. Ingress“ debuggen, gehört ein Blick auf Endpoints/EndpointSlices immer zu den ersten Schritten, weil er die gesamte Kette entscheidet.
TLS-Termination: Warum Ingress den Traffic technisch verändert
Ingress ist nicht nur „Weiterleitung“, sondern häufig eine Terminierungs- und Proxy-Schicht. Wenn TLS am Ingress endet, wird die Verbindung dort entschlüsselt und als neue Verbindung zum Backend aufgebaut (HTTP oder HTTPS, je nach Konfiguration). Dadurch ändern sich Latenz, Quell-IP-Sichtbarkeit, Header und manchmal auch Timeouts. Für Backend-Teams wirkt das oft so, als ob „Ingress kaputt“ ist, obwohl es technisch korrekt arbeitet – nur anders, als erwartet.
Typische Effekte durch TLS-/Proxy-Schichten
- Client-IP: Backend sieht häufig die Proxy-IP; echte Client-IP wird über Header transportiert
- Timeouts: Controller hat eigene Timeouts für Upstream-Verbindungen
- Header: Host, X-Forwarded-For, X-Forwarded-Proto beeinflussen App-Logik
- HTTP-Statuscodes: 4xx/5xx können vom Controller kommen, nicht vom Backend
Debugging-Strategie: Den verwirrenden Pfad in klaren Tests zerlegen
Eine robuste Vorgehensweise ist, den Pfad in unabhängige Teiltests zu schneiden. Dadurch erkennen Sie schnell, ob Service oder Ingress das Problem ist, ohne Vermutungen über Controller-Interna oder Cloud-LB-Details.
- Test 1 (Backend direkt): Pod-IP und Port vom Debug-Pod aus prüfen (rein Service-Downstream)
- Test 2 (Service intern): Service-DNS/ClusterIP und Port vom Debug-Pod prüfen
- Test 3 (Ingress intern): Ingress Controller Service intern ansprechen (falls möglich) und Host-Header setzen
- Test 4 (Ingress extern): Von außen über Domain prüfen (DNS/TLS/LB inklusive)
Wenn Test 1 scheitert, ist es kein Ingress-Problem. Wenn Test 1 klappt, aber Test 2 scheitert, ist es Service/Endpoints/DNS/kube-proxy. Wenn Test 2 klappt, aber Test 3 scheitert, ist es Ingress-Regel/Controller. Wenn Test 3 klappt, aber Test 4 scheitert, ist es DNS/LB/Firewall/TLS außerhalb des Clusters.
Warum „Ingress = LoadBalancer“ in der Cloud oft falsch verstanden wird
In Cloud-Setups existieren oft mehrere Load-Balancing-Schichten: ein Cloud Load Balancer (L4 oder L7) vor dem Cluster, dann der Ingress Controller im Cluster, und dahinter Services. Das sieht aus wie Doppelarbeit, hat aber Gründe: Der Cloud-LB übernimmt externe Erreichbarkeit und ggf. statische IPs, der Ingress Controller übernimmt Kubernetes-nahes Routing, Zertifikatsmanagement und dynamische Backend-Auswahl. Für Cost und Governance ist wichtig zu verstehen, welche Schicht welche Aufgabe erfüllt, damit nicht mehrere LBs unbeabsichtigt parallel betrieben werden.
Best Practices, um Verwirrung dauerhaft zu vermeiden
- Konventionen dokumentieren: Welche Apps gehen über Ingress, welche über LoadBalancer-Services?
- IngressClass standardisieren: Nur definierte Controller zulassen, klare Default-Policy
- Service- und Port-Design konsistent halten: klare Portnamen, TargetPort-Disziplin, eindeutige Labels
- NetworkPolicies „Ingress-aware“ machen: Ingress Controller als Quelle in Allow-Regeln berücksichtigen
- Observability auf jeder Stufe: Ingress-Logs, Service-Metriken, Endpoints-Checks, DNS-Metriken
- Fehlerbilder trainieren: Runbooks mit Pfad-basierten Checks statt „wir schauen mal ins Ingress“
Outbound-Quellen für vertiefendes Verständnis
- Kubernetes Services: Typen, Semantik und Datenpfade
- Kubernetes Ingress: Konzept und Voraussetzungen
- Kubernetes Network Policies: Traffic-Restriktionen im Cluster
- DNS for Services and Pods: CoreDNS und Namensauflösung
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.
