Ingress NGINX wird eingestellt: Ihr Kubernetes-Migrationsleitfaden

Die Einstellung von Ingress NGINX ist nicht länger etwas, das Plattformteams im Backlog lassen können. Wenn Ihre Cluster noch davon abhängen, ist März 2026 eine harte operative Deadline, keine sanfte Erinnerung. Das echte Risiko ist nicht, dass Ihre Workloads sofort stoppen. Das echte Risiko ist, dass sie auf einer nicht mehr gewarteten Edge-Komponente weiterlaufen, was genau die Art von Exposition ist, die eine routinemäßige Plattformentscheidung in einen dringenden Vorfall verwandelt.

Deshalb muss diese Migration wie produktives Traffic-Engineering behandelt werden, nicht als Manifest-Konvertierungsübung. Sie müssen wissen, wo Ingress NGINX läuft, auf welche Verhaltensweisen Ihre Apps stillschweigend angewiesen sind, welches Ersatzmodell zu Ihrer Umgebung passt und wie Sie den Cutover validieren, ohne Benutzer zu überraschen.

Was eingestellt wird und wann

Laut der Ankündigung des Kubernetes-Projekts wird Ingress NGINX am 31. März 2026 eingestellt, danach wird es keine weiteren Releases, Bugfixes oder Sicherheitsupdates geben (Kubernetes Blog). Bestehende Deployments laufen weiter, und Installationsartefakte wie Helm-Charts und Container-Images bleiben verfügbar, aber „läuft noch” ist nicht dasselbe wie „wird noch unterstützt.” Das Kubernetes Steering und Security Response Committee veröffentlichten eine Nachfolgeerklärung, die die Dringlichkeit verstärkt.

Diese Unterscheidung ist wichtig, weil viele Teams keinen unmittelbaren Schmerz spüren werden. Traffic fließt möglicherweise weiter. Dashboards bleiben möglicherweise grün. Am ersten Tag bricht vielleicht nichts offensichtlich. Aber die Komponente erhält keine Fixes mehr für neu entdeckte Schwachstellen, und das ändert das Risikoprofil sofort.

Der erste praktische Schritt ist zu bestätigen, ob Sie es tatsächlich nutzen. In vielen Umgebungen bedeutet das, Cluster, Namespaces, Helm-Releases und Ingress-Klassen zu inventarisieren, anstatt anzunehmen, dass ein neueres verwaltetes Angebot es überall ersetzt hat.

Ein einfaches Migrationsgespräch sollte mit vier Fragen beginnen:

1. Wo läuft Ingress NGINX heute
2. Welche Apps hängen noch davon ab
3. Welche Annotations oder benutzerdefinierten Verhaltensweisen sind im Einsatz
4. Welcher Controller oder welches API-Modell wird es ersetzen

Wenn Sie diese nicht sauber beantworten können, sind Sie nicht bereit für einen sicheren Cutover.

Risiken des Verbleibens auf Ingress NGINX

Der größte Fehler, den Teams machen können, ist die Einstellung wie eine gewöhnliche Deprecation zu behandeln. Das ist nicht nur eine Warnung, dass ein Feature nächstes Jahr weniger modisch sein wird. Es ist ein Sicherheits- und Betriebsproblem.

Nach der Einstellung bedeutet der Verbleib auf Ingress NGINX:

• Keine zukünftigen Bugfixes
• Keine Sicherheitspatches
• Keine offiziellen Updates jeglicher Art
• Wachsende Plattformdrift vom Rest des Kubernetes-Ökosystems
• Mehr operatives Risiko bei jeder Änderung der umliegenden Infrastruktur

Die versteckte Gefahr ist, dass bestehende Deployments oft gut genug weiterlaufen, um keine Aufmerksamkeit zu erregen. Das erzeugt ein falsches Sicherheitsgefühl. Eine nicht unterstützte Edge-Komponente ist immer noch eine Edge-Komponente, und Edge-Komponenten neigen dazu, schwerwiegende Konsequenzen zu haben, wenn sie ausfallen oder exponiert werden.

Es gibt auch ein Planungsrisiko. Kubernetes hat ausdrücklich darauf hingewiesen, dass die verfügbaren Alternativen keine direkten Drop-in-Ersatzlösungen sind. Wenn Ihr Migrationsplan davon ausgeht, dass Sie im letzten Moment einen Controller tauschen können, ohne das Verhalten zu überprüfen, unterschätzen Sie die Arbeit fast sicher.

Deshalb ist die richtige Denkweise nicht „einen Ingress-Controller ersetzen”. Es ist Traffic-Eingang, Routing-Verhalten und Plattform-Ownership neu modellieren.

Gateway API vs. andere Controller-Optionen

Die meisten Teams haben zwei realistische Pfade.

Zu Gateway API migrieren

Gateway API ist die moderne Richtung, die Kubernetes für Service-Networking vorantreibt. Es ist ausdrucksstärker als klassisches Ingress, strukturierter und um klarere organisatorische Rollen herum gestaltet. Anstatt implementierungsspezifisches Verhalten in Annotations zu packen, gibt es Plattformteams ein expliziteres Modell mit Ressourcen wie GatewayClass, Gateway und HTTPRoute.

Das ist üblicherweise die bessere langfristige Wahl, wenn Sie wollen:

• Sauberere Trennung von Verantwortlichkeiten
• Portablere Routing-Konfiguration
• Bessere Multi-Team-Governance
• Reichhaltigere Traffic-Routing-Funktionen
• Einen zukunftsorientierten Plattformstandard

Gateway API ist besonders überzeugend, wenn Ihr Plattformteam bereits über fortgeschrittenere Traffic-Richtlinien, gemeinsame Gateway-Ownership oder KI- und Inferenz-Traffic-Muster nachdenkt. Wenn das auf Ihrer Roadmap steht, ist unser Kubernetes-für-KI-Workloads-Leitfaden ein nützlicher Folgeartikel, weil modernes Traffic-Management noch wichtiger wird, sobald Inferenz- und Multi-Tenant-Workloads ins Spiel kommen.

Auf der Ingress-API bleiben, aber Controller wechseln

Das ist oft der schnellere kurzfristige Pfad. Wenn Ihr Ziel ist, das Einstellungsrisiko schnell zu reduzieren und gleichzeitig Änderungen auf Anwendungsebene zu minimieren, kann ein anderer unterstützter Ingress-Controller die praktischere Brücke sein.

Diese Option kann sinnvoll sein, wenn:

• Ihr Traffic-Modell noch relativ einfach ist
• Ihre Teams heute stark von der Ingress-API abhängen
• Ihre Anwendungseigentümer nicht bereit für breitere Routing-Modelländerungen sind
• Ihre Migrationszeitlinie eng ist

Der Kompromiss ist, dass Sie möglicherweise das Einstellungsproblem von März 2026 vermeiden, ohne die langfristigen Vorteile von Gateway API zu erhalten. Für einige Organisationen ist das trotzdem die richtige Entscheidung. Geschwindigkeit und Unterstützbarkeit zählen.

Der echte Entscheidungsrahmen

Rahmen Sie das nicht als „Was ist technisch am coolsten?” Rahmen Sie es als:

• Wie viel Verhaltensportabilität brauchen wir?
• Wie viel Veränderung können App-Teams gerade absorbieren?
• Wie viel Annotations-Schulden haben wir?
• Brauchen wir ein modernes rollenorientiertes Traffic-Modell?
• Lösen wir für das nächste Quartal oder die nächsten drei Jahre?

Das gibt Ihnen eine bessere Antwort, als zu kopieren, was ein anderes Unternehmen in sozialen Medien gepostet hat.

Fünf Verhaltensweisen, die Teams vor der Migration übersehen

Hier gehen viele Migrationen schief. Manifeste zu konvertieren ist der einfache Teil. Traffic-Verhalten zu bewahren ist der schwere Teil.

Kubernetes hat bereits mehrere Ingress-NGINX-Verhaltensweisen hervorgehoben, die Teams während der Migration überraschen. Selbst eine „erfolgreiche” Manifest-Übersetzung kann die Produktion brechen, wenn Sie diese nicht berücksichtigen.

1. Regex-Verhalten kann breiter sein als Sie denken

Ingress NGINX kann Pfade als reguläre Ausdrücke auf Weisen behandeln, die Teams nicht erwarten, besonders wenn bestimmte Annotations vorhanden sind. Wenn Sie zu Gateway API oder einem anderen Controller migrieren und annehmen, dass Exact- oder Prefix-Verhalten sich gleich überträgt, können Sie das Routing brechen.

2. use-regex kann mehr als eine Pfadregel betreffen

Ein besonders gefährliches Verhalten ist, dass nginx.ingress.kubernetes.io/use-regex: "true" alle Pfade für einen Host über Ingress-NGINX-Ingresses hinweg beeinflussen kann, nicht nur die Regel, wo Sie es zuerst bemerkt haben. Das bedeutet, Tippfehler oder Annahmen, die harmlos aussahen, können tatsächlich Teil Ihres aktuellen Traffic-Verhaltens sein.

3. Rewrite-Regeln können stillschweigend Regex-Matching implizieren

Die rewrite-target-Annotation kann effektiv regex-artiges Verhalten einführen, selbst wenn Sie die Route nicht explizit als regex-basiert betrachtet haben. Teams entdecken dies oft erst, wenn die migrierten Routen strenger werden und zuvor akzeptierte Anfragen 404 zurückgeben.

4. Trailing-Slash-Redirects können verschwinden

Ingress NGINX kann Anfragen ohne abschließenden Schrägstrich zum Pfad mit Schrägstrich weiterleiten. Konforme Gateway-API-Implementierungen fügen diesen Redirect nicht stillschweigend für Sie hinzu. Wenn Clients oder nachgelagerte Systeme von diesem Verhalten abhängen, kann die Migration subtile Brüche erzeugen.

5. URL-Normalisierung kann Match-Ergebnisse ändern

Ingress NGINX normalisiert URLs vor dem Matching und Routing. Wenn Ihre Apps von diesem Verhalten abhängen, kann eine neue Controller- oder Gateway-API-Implementierung äquivalent aussehende Anfragen anders behandeln, es sei denn, Sie stellen das beabsichtigte Verhalten explizit nach.

Die Schlüssellektion ist einfach: Ihr Produktions-Routing-Verhalten ist nicht nur das, was Ihr YAML sagt. Es ist auch, was Ihr Controller tatsächlich mit diesem YAML macht.

Validierung, Rollback und Observability

Eine sichere Migration braucht drei Dinge: Sichtbarkeit vor der Änderung, kontrollierten Cutover während der Änderung und schnelles Rollback, wenn die Realität nicht mit dem Plan übereinstimmt.

Verhalten validieren, nicht nur Syntax

Es reicht nicht, dass Manifeste sauber angewendet werden. Sie müssen testen:

• Exaktes Pfad-Matching
• Prefix-Routing
• Regex-Verhalten
• Rewrites
• Redirects
• TLS-Terminierung
• Header-Handling
• Health Checks
• Auth-bezogenes Edge-Verhalten
• Fehlerantworten

Wenn möglich, erfassen Sie Live-Anfragemuster vor der Migration und spielen Sie repräsentativen Traffic in einer niedrigeren Umgebung ab. Das gibt Ihnen ein viel besseres Signal als das manuelle Testen von zwei oder drei URLs.

Rollback vor dem Cutover planen

Rollback sollte Teil des ersten Migrations-Designmeetings sein, nicht etwas, das Sie improvisieren, nachdem die Änderung zu scheitern beginnt.

Ein echter Rollback-Plan sollte definieren:

• Was zurückgeschaltet wird
• Welche DNS- oder Load-Balancer-Änderungen rückgängig gemacht werden müssen
• Wie lange Rollback dauert
• Wer die Berechtigung hat, es auszulösen
• Welche Daten- oder Konfigurationsänderungen irreversibel sind

Wenn Sie Rollback nicht in fünf Minuten beschreiben können, ist es wahrscheinlich nicht bereit.

Observability vor der Migration verbessern

Teams warten oft bis zur Migrationswoche, um sich die Ingress-Level-Observability anzuschauen. Das ist zu spät.

Bevor Sie umschalten, stellen Sie sicher, dass Sie starke Sichtbarkeit haben über:

• Anfragevolumen
• Status-Code-Verschiebungen
• Latenzperzentile
• TLS-Fehler
• Routenebenen-Traffic-Änderungen
• Backend-Gesundheit
• Redirect-Volumen
• Fehlerspitzen nach Pfad oder Host

Sie wollen nicht, dass Ihr erster Hinweis eine Slack-Nachricht von einem kundenorientierten Team ist. Migrationen sind einfacher, wenn Sie routenebenes Verhalten sofort sehen und alte vs. neue Muster nahezu in Echtzeit vergleichen können.

Sicherheitssichtbarkeit ist ebenfalls wichtig. Die Edge ist Teil Ihrer Vertrauensgrenze, was ein Grund ist, warum eine Migration wie diese zusammen mit Ihrer Zero-Trust-Architekturstrategie überprüft werden sollte, nicht als reine Netzwerkaufgabe behandelt.

Ein phasenweiser Migrationsplan

Die besten Ingress-NGINX-Migrationspläne sind phasenweise, langweilig und höchst intentional. Das ist eine gute Sache.

Phase 1: Inventarisieren und klassifizieren

Beginnen Sie damit, jeden Cluster und jede App zu katalogisieren, die Ingress NGINX nutzt. Gruppieren Sie Workloads nach Traffic-Kritikalität, Komplexität und Annotation-Nutzung.

In dieser Phase suchen Sie nach:

• Benutzerdefinierten Annotations
• Regex-Pfaden
• Rewrite-Regeln
• Redirects
• Geteilten Hostnamen
• Multi-Tenant-Gateway-Mustern
• Auth- und WAF-Integrationen
• Controller-spezifischen CRDs oder Sidecars

Wenn Sie zu Gateway API migrieren wollen, können Tools wie ingress2gateway bei der Übersetzung von Ressourcen helfen, aber die Übersetzung sollte als Beschleuniger behandelt werden, nicht als Korrektheitsbeweis.

Phase 2: Zielmodell wählen

Entscheiden Sie, welche Workloads zuerst zu Gateway API migrieren sollen und welche möglicherweise einen Interims-Controller-Wechsel brauchen. Nicht jede App braucht denselben Pfad.

Ein gängiges Muster ist:

• Einfache interne Apps zuerst
• Nicht-kritische externe Apps als nächstes
• Komplexe oder annotationsintensive Apps später
• Geteilte Edge und geschäftskritischer Traffic zuletzt

Das gibt dem Plattformteam Zeit zum Lernen, ohne den sensitivsten Traffic zuerst zu riskieren.

Phase 3: Eine Verhaltensmatrix erstellen

Für jede App oder Routengruppe dokumentieren Sie:

• Erwartete Pfade
• Redirects
• Rewrites
• Auth-Anforderungen
• TLS-Verhalten
• Header und Cookies
• Backend-Gesundheitserwartungen
• Fehlerbedingungen

Das wird zum Vertrag, den Sie vor und nach dem Cutover validieren.

Phase 4: Paralleltests durchführen

Wo möglich, betreiben Sie das Zielmodell parallel und vergleichen das Verhalten. Das kann gespiegelten Traffic, alternative Hostnamen, Canary-Einstiegspunkte oder gestaffelte Cutovers nach Umgebung bedeuten.

Diese Phase ist, wo Überraschungen sichtbar werden, während der Schadensradius noch klein ist.

Phase 5: In Wellen umschalten

Bewegen Sie sich in kontrollierten Wellen mit klaren Erfolgsmetriken, Rollback-Triggern und besetzter Ownership. Kombinieren Sie die Ingress-Migration nicht mit fünf unzusammenhängenden Plattformänderungen im selben Fenster.

Phase 6: Alte Abhängigkeiten entfernen

Sobald der Traffic stabil ist, entfernen Sie veraltete Ingress-Klassen, Helm-Releases, Controller-Konfigurationen und Team-Annahmen, die noch auf Ingress NGINX zurückverweisen. Eine Migration ist nicht abgeschlossen, bis die Abhängigkeit tatsächlich weg ist.

Laden Sie ein Cluster-Migrations-Inventar-Worksheet herunter

Die Einstellung von Ingress NGINX ist dringend, aber Dringlichkeit ist kein Grund, blind zu hetzen. Teams, die gut migrieren, werden dies als Traffic-Verhaltensprojekt, als Plattform-Governance-Projekt und als Sicherheitsexpositions-Projekt gleichzeitig behandeln.

Der praktischste nächste Schritt ist, ein Cluster-Migrations-Inventar-Worksheet zu erstellen, das jede Ingress-Klasse, jeden Hostnamen, jede Annotation, jeden Rewrite, jeden Redirect, jede TLS-Abhängigkeit und jeden Rollback-Verantwortlichen an einem Ort erfasst. Dieses Dokument wird wertvoller sein als eine generische „Wir sollten zu Gateway API wechseln”-Aussage.

Holen Sie sich das kostenlose Cluster-Migrations-Inventar-Worksheet →

Verbinden Sie von dort aus Ihre Migrationsarbeit mit unserem Kubernetes-für-KI-Workloads-Leitfaden, unserer Roadmap für Software-Lieferkettensicherheit und unserem Zero-Trust-Architekturleitfaden, damit Ihre Edge-Migration die breitere Plattform stärkt, anstatt nur eine alternde Komponente durch eine andere zu ersetzen.