Ingress

YAML "Wunschzettel":

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: shop.de
    http:
      paths:
      - path: /api
        backend:
          service:
            name: api-service
            port: { number: 80 }

Wichtig: Das Ingress-Objekt allein tut nichts. Du brauchst einen Ingress Controller (ein Programm, das diesen Wunschzettel liest und umsetzt). Standard ist oft Nginx Ingress Controller oder Traefik.

Praxisroutine

In der Praxis lernst du Ingress, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. Ingress vs. Gateway API

Ingress (die API) ist alt und limitiert. Es kann nur HTTP(S). Kein TCP, kein UDP, keine komplexen Traffic-Splits (Canary 5%). Jeder Controller (Nginx, HAProxy) hat eigene, inkompatible Annotationen erfunden (nginx.ingress.kubernetes.io/rewrite-target). Die Zukunft ist die Gateway API. Sie ist mächtiger, standardisiert und unterstützt Multi-Team Rollen (Infra-Team verwaltet Gateway, App-Team verwaltet Routes). Ingress ist "Legacy", aber immer noch 90% Marktanteil.

2. SSL Termination

Der Ingress ist meistens der Punkt, wo HTTPS endet (Terminierung). Er entschlüsselt das Paket. Ab da geht es oft unverschlüsselt (HTTP) weiter zu den Pods (Performance). Der Ingress verwaltet die Zertifikate (oft automatisch via Cert-Manager + Let's Encrypt). Du definierst im Ingress: tls: - secretName: my-cert. Der Controller lädt das Zertifikat in den RAM.

3. Fanout & Name-based Virtual Hosting

Ingress spart Geld. Du hast einen einzigen Cloud LoadBalancer (kostet 20€/Monat). Dahinter hängt der Ingress Controller. Der Ingress Controller bedient 100 Domains (a.com, b.com, c.com). Er schaut in den Host-Header und routet intern. Das nennt man Fanout. Massive Skalierung mit minimaler Infrastruktur.

In-Cluster Data Path (NodePort vs. HostPort)

Wie kommt der Traffic vom AWS LoadBalancer in den echten Nginx-Pod (den Controller)? Hier existieren oft eklatante Missverständnisse. Normalerweise wird der Ingress Controller via ServiceType: LoadBalancer exponiert. Der Cloud-LB schickt das Paket (via NodePort) blind an jeden Worker-Node (z. B. auf Port 31080). kube-proxy fängt das Paket per iptables ab und jagt es netzwerkintern zu dem Worker-Node, auf dem der Nginx-Pod tatsächlich lebt (Extra Hop). Für massive Performance (Low Latency) schaltet man externalTrafficPolicy: Local. Dann leitet der Cloud-LB das Paket nur an die physikalischen Nodes weiter, auf denen auch wirklich ein Ingress-Pod läuft. Der Extra-Hop via kube-proxy entfällt komplett, und Source-IP-Adressen der Kunden bleiben erhalten statt von K8s NAT maskiert zu werden.

Header-Injection (X-Forwarded-For)

Sitzt dein App-Container hinter einem Ingress, verschleiert der Ingress als Proxy die originale IP des Endnutzers. Der Traffic scheint logisch vom Ingress-Pod zu stammen. Damit Rate-Limiting oder Geo-IP-Auswertungen in der App nicht kollabieren, muss der Controller den HTTP-Header X-Forwarded-For (oder in neuerem Standard Forwarded) injizieren. Bei mehrstufigen CDN-Setups (Cloudflare -> AWS LB -> Ingress) reichert jeder Proxy diesen Header iterativ um seine IP an. Die Application muss konfiguriert sein, dem Ingress (trust-proxy) zu glauben, sonst droht IP-Spoofing durch gefälschte Kunden-Header.

Ingress als Web Application Firewall (WAF)

Der Ingress ist der einzige Flaschenhals, durch den jeglicher externer Traffic fließen muss – ein perfekter Ort für Security. Enterprise-Controller (wie Nginx Plus oder ModSecurity-Module) verwandeln den simplen Router in eine WAF (Web Application Firewall). Noch bevor der Request den winzigen Python-Microservice erreicht, analysiert der Ingress den Payload auf verdächtige Regex-Muster (SQL-Injections, XSS-Cross-Site Scripting). Das Entkoppeln der WAF von der Applikation bedeutet, dass du alle 50 Microservices deines Clusters mit einer einzigen Zeile Konfiguration (Annotation im Ingress) global gegen Log4j-ähnliche Exploits absichern kannst, ohne jemals Code im Backend anpassen zu müssen.