Ingress

Ingress

Ein Ingress ist eine Kubernetes-Ressource, mit der sich HTTP- und HTTPS-Anfragen von außen gezielt zu Services im Cluster weiterleiten lassen.
Anstatt für jeden Service separat einen NodePort oder einen eigenen Load Balancer bereitzustellen, bündelt ein Ingress den Zugriff und leitet Anfragen anhand klar definierter Routing-Regeln weiter – zum Beispiel abhängig vom Hostname (shop.example.com) oder vom Pfad (/api, /images).

Der Ingress selbst ist nur eine Beschreibung der gewünschten Weiterleitung. Damit diese Regeln tatsächlich greifen, benötigt man einen Ingress-Controller (z. B. NGINX, Traefik oder Istio).
Dieser Controller liest die Ingress-Definitionen aus der Kubernetes-API aus und übersetzt sie in konkrete Konfigurationen für den darunterliegenden Reverse Proxy.

Vorteile eines Ingress:

  • Zentrale Steuerung des externen HTTP/HTTPS-Zugriffs
  • Weniger öffentliche IP-Adressen nötig
  • Unterstützung für TLS-Terminations, Weiterleitungen, Rewrites und mehr
  • Leicht erweiterbar mit Middleware (z. B. Authentifizierung, Ratenbegrenzung)

Warum braucht man Ingress?

  1. Konsolidierung externer Endpunkte
    Statt für jeden Service eine eigene öffentliche IP oder LoadBalancer‑Instanz zu konfigurieren, nutzt man einen einzigen Entry‑Point (Ingress) für viele Services.
  2. Flexible Routing‑Regeln
    – Host‑basierte Weiterleitung (z. B. foo.example.com → Service A; bar.example.com → Service B)
    – Pfad‑basierte Weiterleitung (z. B. /api → API‑Service; /ui → Frontend‑Service)
  3. TLS‑Terminierung
    Zertifikate werden zentral im Ingress verwaltet, der Controller terminiert das TLS, Service‑Pods können unverschlüsselt kommunizieren.
  4. Zusätzliche Features
    Authentifizierung, Rate‑Limiting, Rewrite‑Regeln, Access‑Logs, WAF‑Integration – je nach Controller erweiterbar.

Ingress-Controller

Kubernetes bringt die Ingress-Funktion selbst nicht mit – es liefert nur die API, über die du Ingress-Regeln beschreiben kannst. Damit diese Regeln tatsächlich wirken, braucht es einen Ingress-Controller.

Kubernetes stellt für Ingress nur die API bereit, mit der sich Routing-Regeln definieren lassen, implementiert die Funktionalität aber nicht selbst. Damit diese Regeln tatsächlich angewendet werden, benötigt man einen Ingress-Controller. Dieser läuft als Pod im Cluster, überwacht kontinuierlich die vorhandenen Ingress-Ressourcen und übersetzt deren Definitionen in die Konfiguration eines HTTP/HTTPS-Proxys wie beispielsweise NGINX. Anschließend betreibt er diesen Proxy so, dass der eingehende Datenverkehr entsprechend den festgelegten Regeln zu den richtigen Services weitergeleitet wird. Je nach Einsatzzweck kann ein Ingress-Controller als Deployment, DaemonSet oder über einen externen LoadBalancer bereitgestellt werden. Bekannte Implementierungen sind der NGINX Ingress Controller, Traefik sowie das Istio Gateway im Rahmen eines Service Mesh.

Typische Beispiele:

  • NGINX Ingress Controller – weit verbreitet, stabil und gut dokumentiert
  • Traefik – leichtgewichtig, flexibel und mit vielen Cloud-Integratione
  • Istio Gateway – Bestandteil von Service-Mesh-Architekturen
Die Kommentare sind geschlossen.