Site icon bintorosoft.com

Service vs. Ingress: Der oft verwirrende Traffic-Pfad

Red Snapper

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.

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.

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

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

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

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.

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

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“

„Ingress antwortet, aber Backend gibt 502/504“

„Nur über Service-Name geht es nicht, über Pod-IP schon“

„Client-IP ist im Pod-Log immer die Ingress-IP“

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.

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.

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

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.

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

Outbound-Quellen für vertiefendes Verständnis

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