Nach dem Ende von ingress-nginx: eine parallele Migration zur Gateway API validieren

Worum es geht

Stand: 25. Oktober 2026. Die Kubernetes-Community legte in ihrer Ankündigung zur Einstellung von Ingress NGINX den März 2026 als Ende der Wartung nach dem Best-Effort-Prinzip fest; danach gibt es keine weiteren Versionen, Fehlerkorrekturen oder Sicherheitsupdates. Bestehende Deployments und Installationsartefakte bleiben nutzbar. Vor der Planung einer Änderung die Ankündigung und die Support- und Konformitätsdokumentation des gewählten Ersatzcontrollers erneut prüfen. Dies betrifft das Community-Projekt ingress-nginx; den tatsächlichen Controller bestimmen, statt alles mit dem Namen NGINX gleich einzuordnen. Ankündigung der Einstellung.

Warum es wichtig ist

Ein verfügbares Image oder ein funktionierender Endpunkt belegt keine fortlaufende Wartung. Die Gateway API ändert das Konfigurationsmodell: Ein Gateway beschreibt Zugangspunkte, während HTTPRoute das Anwendungsrouting beschreibt. Controllerspezifische Annotationen benötigen eine explizite Zuordnung. Der allgemeine Migrationsleitfaden erklärt die Konvertierung, bietet jedoch ausdrücklich kein vollständiges Verfahren für eine Migration im laufenden Betrieb. Migrationsmodell.

Das folgende schrittweise Verfahren ist ein Vorschlag für einen Betriebsplan. Seine Abnahmekriterien müssen die bestehenden Routing- und Sicherheitsanforderungen der Anwendung abdecken.

So wird es angewendet

• Controller in jedem Cluster erfassen, für den eine entsprechende Autorisierung vorliegt. Die Ankündigung der Einstellung schlägt kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx vor. Auch Controller-Deployments und Images prüfen: Eine Label-Abfrage allein kann umbenannte oder angepasste Installationen nicht ausschliessen. Ingress-Ressourcen, Klassen, Annotationen, TLS-Referenzen und die Controllerkonfiguration festhalten.

• Eine gewartete Gateway-API-Implementierung wählen, deren Konformität und Erweiterungsunterstützung die benötigten Funktionen abdecken. Zuständigkeiten für Zugangspunkte und Routen festlegen. Der offizielle Einstiegsleitfaden sieht vor, den neuen Controller mit einer anderen externen IP parallel zu ingress-nginx zu betreiben; deshalb vor der Umstellung des öffentlichen Datenverkehrs einen separaten Validierungsendpunkt einrichten. Leitfaden für die parallele Migration.

• Mit einer geprüften ingress2gateway-Installation aus exportierten Manifesten einen Entwurf erzeugen. Die offizielle Ankündigung zu 1.0 dokumentiert diese Form:

  ingress2gateway print --input-file ingress.yaml --providers=ingress-nginx > gateway-draft.yaml
  

  Die erzeugten Ressourcen und sämtliche Warnungen vor jeder Anwendung prüfen. Die tatsächliche Ersatz-GatewayClass auswählen und Namen, Namespaces sowie Backend-Referenzen kontrollieren. Konvertierungsleitfaden.

• Für jede nicht unterstützte Funktion ausdrücklich eine Lösung festlegen. Die Ankündigung nennt nicht konvertierte Konfigurationsfragmente, näherungsweise übertragene Timeout-Einstellungen, im gezeigten Beispiel Grössenbeschränkungen für den Request-Body ohne Entsprechung im Standard sowie Unterschiede bei der URL-Normalisierung. Diese Zuordnungen anhand der heutigen API und der gewählten Implementierung erneut prüfen; aus einer früheren Beschränkung des Konverters keine dauerhafte Aussage über die Spezifikation ableiten.

• Den separaten Endpunkt mit dem vorgesehenen Hostnamen und der TLS-Identität validieren. Weiterleitungen, Authentifizierungsanforderungen, Routenvorrang, Uploads, lang laufende Anfragen und das erwartete Ablehnungsverhalten testen. Dies als gewöhnliche Anwendungstests ohne Angriffspayloads durchführen. Die Ergebnisse mit den dokumentierten Anforderungen vergleichen; es genügt nicht, dass beide Endpunkte eine erfolgreiche Antwort liefern.

• Den Datenverkehr über den kontrollierten DNS- oder Load-Balancer-Änderungsprozess der Website umstellen. Anwendungsfehler und Zugriffslogs beobachten, einen zeitlich begrenzten Rollback-Weg bereithalten und nach erfolgreicher Beobachtungsphase den alten Controller sowie ungenutzte Ressourcen entfernen.

Stolpersteine

Nicht davon ausgehen, dass erzeugtes YAML Zugriffskontrollen erhält oder benutzerdefinierte Erweiterungen zwischen Controllern übertragbar sind. Auch ein paralleles Deployment erfordert klare Zuständigkeiten für DNS und Zertifikatsautomatisierung. Den eingestellten Controller nicht auf unbestimmte Zeit als undokumentierte Reserve erreichbar lassen. Erfolgreiche Konvertierung, Betriebsbereitschaft des Controllers und korrektes Anwendungsverhalten sind getrennte Prüfungen.