Kubernetes Ingress ist das API-Objekt für HTTP- und HTTPS-Routing von außen in den Cluster. Während ein Service auf Ebene 4 (TCP/UDP) arbeitet, lenkt Ingress den Verkehr auf Ebene 7 (HTTP) — nach Hostname und URL-Pfad. Als moderner Nachfolger etabliert sich die Kubernetes Gateway API mit standardisierten Routing-Regeln.
Regeln und Controller
Eine Ingress-Ressource definiert Regeln: Welcher Host und welcher Pfad soll an welchen Service gehen? Dazu kommen der pathType (Prefix oder Exact) und optional TLS-Einstellungen. Die Ressource allein macht noch nichts — ein Ingress-Controller (zum Beispiel NGINX, HAProxy, Traefik oder Envoy) setzt die Regeln in die Proxy-Konfiguration um.
Welcher Controller zuständig ist, bestimmt die IngressClass-Ressource: Sie verweist per spec.controller auf eine Controller-Implementierung und wird je Ingress über ingressClassName gewählt.
Warum Ingress?
Statt für jeden Dienst einen eigenen Load Balancer zu erzeugen, teilen sich viele Services einen einzigen Einstiegspunkt. Das spart Kosten und vereinfacht das Zertifikatsmanagement: Die TLS-Terminierung übernimmt der Controller mit einem Zertifikat aus einem Kubernetes-Secret.
Die Verwaltung der Ingress-Objekte läuft über die Control-Plane: Der kube-apiserver speichert die Regeln, und Komponenten wie der kube-controller-manager halten die Cluster-Verwaltung am Laufen.
Verwandte Grundlagen: Kubernetes, Helm, TLS-Handshake, Service Mesh.