Der März hat begonnen – und damit auch der letzte Abschnitt für eine der meistgenutzten Komponenten im Kubernetes-Netzwerkstack: Ingress-NGINX wird in diesem Monat offiziell eingestellt.

Für viele Unternehmen kommt dieser Zeitpunkt überraschend nah. In unzähligen Kubernetes-Clustern läuft Ingress-NGINX seit Jahren stabil und zuverlässig im Hintergrund. Genau das macht die Situation jedoch trügerisch. Denn viele Setups basieren auf impliziten Verhaltensweisen und historischen Defaults, die bei einer Migration zur Gateway API nicht automatisch übernommen werden.

Die Folge: Eine scheinbar saubere Migration kann plötzlich zu Routing-Fehlern, unerwarteten 404-Antworten oder Traffic-Ausfällen führen.

Wer jetzt mit der Umstellung beginnt, sollte daher nicht nur YAML-Dateien übersetzen, sondern verstehen, welche versteckten Mechanismen Ingress-NGINX bisher im Hintergrund erledigt hat.

Warum Kubernetes Networking gerade neu gedacht wird

Die ursprüngliche Idee der Ingress-API war relativ simpel: HTTP-Routing innerhalb von Kubernetes standardisieren. In der Praxis entwickelte sich daraus jedoch ein komplexes Ökosystem aus Controller-spezifischen Erweiterungen, Annotations und individuellen Interpretationen der Spezifikation.

Ingress wurde damit zunehmend zu einem technischen Kompromiss.

Die Gateway API ist die Antwort der [Kubernetes]-Community auf diese Entwicklung. Sie trennt Verantwortlichkeiten klarer, bietet eine strukturierte Erweiterbarkeit und ermöglicht es Plattformteams, Networking zentral zu steuern, ohne die Flexibilität für Anwendungsteams einzuschränken.

Für moderne Plattformarchitekturen ist das ein wichtiger Schritt: Kubernetes Networking wird dadurch strukturierter, transparenter und besser governable.

Doch genau dieser Schritt macht Migrationen anspruchsvoll.

Die versteckten Eigenheiten von Ingress-NGINX

Viele [Kubernetes]-Cluster nutzen heute Verhalten von Ingress-NGINX, das nie Teil der eigentlichen Ingress-Spezifikation war. Über die Jahre haben sich bestimmte Mechanismen etabliert, die häufig unbemerkt bleiben – solange alles funktioniert.

Erst bei einer Migration zur Gateway API wird sichtbar, wie stark manche Anwendungen davon abhängen.

Regex-Matching funktioniert anders als erwartet

Ein Beispiel sind Regex-basierte Pfadrouten.

Auf den ersten Blick scheint ein Pattern wie /[A-Z]{3} klar definiert: Es soll Pfade mit drei Großbuchstaben matchen. Ingress-NGINX funktioniert das jedoch anders als viele erwarten.

Das Matching erfolgt dort häufig prefix-basiert und nicht case-sensitiv. Dadurch können auch Requests wie /uuid oder /uuid/test unerwartet auf diese Route passen.

Viele Gateway-Implementierungen – etwa Envoy-basierte Controller – verwenden dagegen eine klassische Regex-Semantik mit case-sensitivem Matching. Nach der Migration kann derselbe Request deshalb plötzlich nicht mehr gematcht werden und endet mit einem 404.

Eine Annotation kann mehrere Ingress-Ressourcen beeinflussen

Ein weiteres Beispiel ist die Annotation use-regex.

Wird sie in einer Ingress-Ressource aktiviert, kann Ingress-NGINX plötzlich alle Pfade eines Hosts als Regex interpretieren – selbst dann, wenn sie in anderen Ingress-Objekten definiert wurden.

Das führt zu Situationen, in denen kleine Tippfehler unbemerkt bleiben. Ein Pfad wie /Header kann plötzlich auch /headers matchen, obwohl die Route eigentlich als exakter Match gedacht war.

In der Gateway API existiert dieses implizite Verhalten nicht. Routen werden dort strikt entsprechend ihrer Definition ausgewertet.

Rewrite-Regeln verändern mehr als nur URLs

Viele Teams nutzen die Annotation rewrite-target, um Pfade umzuschreiben. Was dabei oft übersehen wird: Diese Funktion aktiviert intern ebenfalls Regex-Verhalten.

Das bedeutet, dass plötzlich dieselben Nebeneffekte auftreten wie bei use-regex – etwa case-insensitive Matches oder prefix-basierte Interpretation von Pfaden.

Auch hier gilt: Solche Mechanismen können über Jahre funktionieren, ohne dass sie bewusst eingeplant wurden. Erst bei der Migration fällt auf, dass Anwendungen ungewollt davon abhängig geworden sind.

Automatische Redirects bei fehlendem Slash

Ingress-NGINX hilft außerdem an Stellen, an denen viele Entwickler es gar nicht bemerken.

Wenn eine Route beispielsweise /my-path/ lautet und ein Client /my-path aufruft, erzeugt Ingress-NGINX automatisch einen 301-Redirect auf die Variante mit dem abschließenden Slash.

Gateway-API-Implementierungen machen das nicht automatisch. Ohne explizite Konfiguration würde derselbe Request plötzlich mit einem 404-Fehler beantwortet werden.

Solche Details wirken klein, können aber reale Auswirkungen auf Anwendungen, APIs oder Frontends haben.

Automatische URL-Normalisierung

Ein weiteres Verhalten betrifft die sogenannte URL-Normalisierung.

Ingress-NGINX bereinigt ungewöhnliche Pfadstrukturen automatisch, bevor Routing-Regeln angewendet werden. Dazu gehört beispielsweise:

• das Entfernen doppelter Slashes
• das Auflösen von . oder .. Segmenten
• die Umwandlung verschiedener Pfadvarianten in eine kanonische Form

Viele moderne Gateway-Implementierungen übernehmen ähnliche Mechanismen, jedoch nicht immer identisch. Unterschiede können deshalb ebenfalls zu unerwarteten Routing-Ergebnissen führen.

Wie Plattformteams jetzt sinnvoll vorgehen

Da der Abschied von Ingress-NGINX bereits begonnen hat, lohnt sich ein strukturierter Blick auf bestehende Konfigurationen.

Der wichtigste erste Schritt ist eine Analyse der aktuellen Ingress-Ressourcen. Welche Annotations werden genutzt? Gibt es Regex-Routen? Werden Rewrite-Regeln verwendet? Schon diese Fragen zeigen häufig, wo potenzielle Risiken liegen.

Ebenso wichtig ist ein Blick auf das tatsächliche Traffic-Verhalten der Clients. Viele Anwendungen nutzen unterschiedliche Varianten von URLs – etwa mit oder ohne Slash, mit variierender Groß- und Kleinschreibung oder mit ungewöhnlichen Pfadstrukturen.

Access Logs und Observability-Daten liefern hier oft wertvolle Hinweise.

In der Praxis hat sich außerdem ein paralleler Migrationsansatz bewährt. Dabei wird die Gateway API zunächst zusätzlich zum bestehenden Ingress betrieben. Traffic kann gespiegelt oder schrittweise umgeleitet werden, um Unterschiede im Routing frühzeitig zu erkennen.

Fazit

Der März 2026 markiert einen wichtigen Moment im [Kubernetes]-Ökosystem. Mit dem Ende von Ingress-NGINX beginnt für viele Plattformteams der Übergang zur Gateway API – und damit zu einer moderneren und klarer strukturierten Networking-Architektur.

Diese Migration ist jedoch mehr als ein einfaches Umstellen von YAML-Konfigurationen. Viele Cluster verlassen sich auf implizite Verhaltensweisen, die über Jahre unbemerkt geblieben sind.

Wer diese Details frühzeitig analysiert und Migrationen kontrolliert testet, kann den Übergang sicher gestalten – und gleichzeitig die Grundlage für eine robustere und zukunftsfähige [Kubernetes]-Plattform schaffen.