Die Migration von Ingress NGINX wird zwingend erforderlich: EOL und Sicherheitsanfälligkeiten machen den Übergang zum Kubernetes Gateway API zu einer Frage der Stabilität und Sicherheit.
Das Problem zeigt sich nicht sofort — bis der Zugriff auf den eingehenden Datenverkehr zu einem systemischen Risiko wird. Ingress NGINX war lange Zeit der De-facto-Standard für Kubernetes, aber sein Lebenszyklus ist beendet. Das bedeutet, dass es keine zukünftigen Sicherheitspatches mehr geben wird. Vor diesem Hintergrund zeigen Sicherheitsanfälligkeiten wie IngressNightmare und neue CVEs ein wichtiges Detail: Der Ingress-Controller ist kein isoliertes Element, sondern ein Punkt mit einem clusterweiten Schadensradius. Dabei bleibt die Kubernetes Ingress API bestehen, ist jedoch in ihrer Funktionalität faktisch eingefroren. Das System funktioniert weiterhin, entwickelt sich jedoch nicht weiter.
Die Lösung in dieser Situation ist der Übergang zum Kubernetes Gateway API. Dies ist kein spezifischer Controller, sondern eine Spezifikation mit einer Reihe von Ressourcen. Dieser Ansatz beseitigt die Abhängigkeit von Anmerkungen, die zuvor an Ingress NGINX gebunden waren. Stattdessen wird das Routing deklarativ über Standardressourcen beschrieben. Dies verringert den Vendor Lock-in und macht Konfigurationen zwischen Implementierungen portierbar. Der Kompromiss ist hier offensichtlich: Verhalten und Konformitätsgrad können zwischen den Controllern variieren. Auch die Unterstützung von Protokollen ist wichtig zu berücksichtigen. HTTP wird überall abgedeckt, aber TCP und UDP sind nicht garantiert.
Ein entscheidender architektonischer Schritt ist die Auswahl des Controllers. Er bestimmt das Verhalten der Datenebene und die verfügbaren Möglichkeiten. Zum Beispiel ist für LLM-Lasten die Unterstützung von Erweiterungen wie Inference Routing wichtig, die von spezifischen Implementierungen abhängen (z. B. über ext_proc). Danach beginnt die eigentliche Migration. Sie wird als paralleler Prozess aufgebaut und nicht als „Umschalten des Schalters“. Zuerst wird ein Basiswert festgelegt: Anfragefrequenz, Latenz, Fehlerquote. Diese Metriken sind nicht für Berichte gedacht, sondern als Kontrollpunkt, um zu verstehen, ob das Verhalten des Systems beeinträchtigt wird.
Die Implementierung beginnt mit der Installation der Gateway API CRDs und des gewählten Controllers. Die grundlegenden Entitäten sind GatewayClass, Gateway, Route und ReferenceGrant. Im Gegensatz zu Ingress, wo viele Dinge „standardmäßig funktionierten“, werden hier die Verbindungen explizit. Zum Beispiel erfordert der Zugriff über mehrere Namespaces jetzt ein ReferenceGrant. Dies erhöht die Sicherheit, fügt jedoch betriebliche Komplexität hinzu. Ein Fehler in diesen Verbindungen zeigt sich sofort — die Route wird nicht akzeptiert (Accepted: False oder ResolvedRefs: False).
Um die Migration zu beschleunigen, wird das Tool Ingress2Gateway verwendet. Es übersetzt bestehende Manifeste und sogar Teile von Anmerkungen in das neue Format. Aber dies ist nur der Ausgangspunkt. Eine manuelle Überprüfung ist unerlässlich, da nicht alle Konstruktionen eine direkte Entsprechung haben. Nach der Generierung der Konfiguration werden Gateway- und Route-Ressourcen erstellt, die die aktuelle Logik widerspiegeln: Hosts, Pfade, TLS, Backend-Dienste.
Ein kritischer Punkt ist die Validierung ohne Produktionsverkehr. Es werden Shadow- oder synthetische Anfragen verwendet. Die Antworten über den alten und den neuen Einstiegspunkt werden verglichen. Statuscodes, Header, TLS-Verhalten und die tatsächliche Zustellung der Anfrage an das Backend werden überprüft. Dies ermöglicht es, Abweichungen vor dem DNS-Cutover zu erfassen. Wenn der Gateway eine externe Adresse hat, kann das Testen direkt durchgeführt werden, indem der Produktions-Hostname eingesetzt wird.
Der Verkehrswandel erfolgt über DNS. Dies ist kein sofortiger Prozess. Selbst bei niedrigem TTL verwenden einige Clients weiterhin alte Einträge. In dieser Zeit arbeitet das System faktisch im Split-Traffic-Modus. Dies erzeugt zusätzliche Belastungen für die Observability. Abweichungen vom Basiswert müssen überwacht werden: Anstieg der Latenz, Spitzen bei 4xx/5xx, Probleme mit TLS. Wichtig ist, dass ein Rollback einfach bleibt — es reicht aus, DNS zurückzusetzen.
Die Observability wird zum zentralen Element der Migration. Die Metriken von Ingress NGINX werden mit den Metriken von Gateway API in einem einheitlichen Dashboard verglichen. Viele Controller geben Daten im Prometheus-Format aus, was die Integration erleichtert. Zusätzlich wird Tracing (APM) verwendet, um zu verstehen, wo die Verschlechterung auftritt — am Edge oder innerhalb der Dienste. Dieser Ansatz verwandelt die Migration von einem risikobehafteten Ereignis in einen kontrollierten Prozess.
Das Ergebnis ist ein strengeres und vorhersehbares Routing-Modell. Gateway API macht das Verhalten des Systems explizit und portierbar. Aber der Preis ist ein Anstieg der Komplexität und die Notwendigkeit, die Beziehungen zwischen den Ressourcen besser zu verstehen. Metriken zu Verbesserungen in den Ausgangsdaten werden nicht angegeben, daher wird der Effekt über Stabilität, Sicherheit und Manageability der Architektur bewertet.