Die Kladde läuft im Cluster. Ihr Service kladde-web ist vom Typ ClusterIP (Lektion W1.2) und damit von außen unerreichbar: Er hat eine Adresse, die nur Pods im Cluster kennen. Diese Lektion beantwortet die Frage, die danach kommt: Wie kommt ein Aufruf von https://kladde.example.com aus dem Internet zu einem Pod, und wer entscheidet unterwegs über Namen, Pfade, TLS und die Verteilung auf Versionen?

Die klassische Antwort heißt Ingress. Sie ist seit Kurzem keine gute Antwort mehr, und das ist der Grund, warum diese Lektion bei der Gateway API ansetzt und Ingress nur als Begründung und als Migrationshinweis behandelt.

Von außen nach innen

Ein Service vom Typ ClusterIP ist nur im Cluster erreichbar. Damit Verkehr von außen hineinkommt, braucht der Cluster zwei Dinge: eine Adresse, die von außen erreichbar ist (bei AKS ein Azure Load Balancer mit öffentlicher IP, im Cluster ein Service vom Typ LoadBalancer), und einen Proxy dahinter, der Anfragen nach Host und Pfad auf die Services verteilt. Wer den Proxy betreibt und wie er konfiguriert wird, ist die eigentliche Frage:

  • Ingress ist ein Kubernetes-Objekt, das Regeln beschreibt (Host, Pfad, Service, TLS). Es tut allein nichts: Ein Ingress-Controller im Cluster muss die Regeln lesen und einen Proxy danach einrichten. Das Kubernetes-Projekt sagt heute selbst, dass es statt Ingress die Gateway API empfiehlt, und dass die Ingress-API eingefroren ist: Sie bleibt allgemein verfügbar, wird aber nicht mehr weiterentwickelt.
  • Gateway API ist der Nachfolger: mehrere Objekte statt einem, mit klaren Zuständigkeiten, mit mehr Möglichkeiten im Standard und weniger Herstellerschalter.

Warum Ingress-NGINX ausläuft

Das verbreitetste Ingress-Controller-Projekt, Ingress-NGINX, wird upstream nicht mehr gewartet. Das Kubernetes-Projekt hat die Einstellung des Projekts angekündigt und die Wartung beendet. Das AKS-Add-on „Application Routing“ mit NGINX baut darauf auf: Microsoft liefert dafür nur noch kritische Sicherheitsupdates, bis zu einem Stichtag, den die Seite zur Migration auf Microsoft Learn nennt (lesen Sie ihn dort, er ändert sich nicht durch diese Lektion), und fordert Nutzer auf, bis dahin zu wechseln. Wer das NGINX-Add-on nutzt, muss auf die Gateway-API-Umsetzung des Add-ons oder auf eine andere unterstützte Lösung umziehen. Neue AKS-Automatic-Cluster nutzen ab AKS 1.36 standardmäßig die Gateway API über das Application-Routing-Add-on.

Ingress hatte schon vorher Schwächen, die das Gateway-API-Projekt nennt:

  • Wenige Möglichkeiten im Standard. Die Ingress-API kennt nur TLS-Beendigung und einfaches Routing nach Inhalt. Alles andere (Umleitungen, Umschreiben, Gewichte) steckt in Anmerkungen (Annotationen) eines Herstellers.
  • Anmerkungen sind nicht übertragbar. Wer den Controller wechselt, verliert die Konfiguration, die in den Anmerkungen steckte.
  • Das Rechtemodell passt nicht zu mehreren Teams. Ein Objekt enthält Entscheidungen des Betriebs (Port, TLS) und der Entwicklung (Pfade) zusammen.