Ingress-NGINX läuft aus: So migrierst du bis März 2026 sauber

Der von der Kubernetes-Community gepflegte Ingress-NGINX Controller (Repository kubernetes/ingress-nginx) erreicht im März 2026 sein offizielles Lebensende. Ab dann gibt es keine Releases, keine Bugfixes und keine Security-Patchesmehr. Bestehende Installationen „brechen" zwar nicht sofort – aber sie laufen anschließend unkontrolliert weiter: neue CVEs, neue Kubernetes-Versionen, neue Inkompatibilitäten – ohne Upstream-Fixes.

Wichtig: Das betrifft nicht NGINX als Webserver. Es geht um den Kubernetes-Controller aus der Community (ingress-nginx), nicht um das NGINX-Projekt.

Die gute Nachricht: Du musst nicht in einem Schritt auf eine komplett neue Konfigurationswelt wechseln. Es gibt Migrationen, die sich wie ein „Soft Landing" anfühlen – inklusive Weiterverwendung vieler klassischer Ingress-NGINX-Annotationen.

Warum das Thema jetzt auf die Agenda gehört

Ingress ist ein Edge- und Security-Baustein. Sobald es keine Patches mehr gibt, wird aus „läuft doch" ein Risiko, das spätestens bei:

• Security-Audits / ISO 27001 / SOC 2
• Kundenanforderungen (Supply Chain, Patch-Management)
• Regulatorik (je nach Branche)
• Kubernetes-Upgrades

unangenehm sichtbar wird.

Kubernetes selbst formuliert es sehr direkt: Nach März 2026 keine weiteren Updates zur Behebung neu entdeckter Sicherheitslücken.

Was endet genau – und was nicht?

Endet: kubernetes/ingress-nginx

• Best-effort Wartung bis März 2026
• Danach: read-only, keine Releases, keine Fixes

Endet nicht: Kubernetes Ingress als API

Du kannst weiterhin Ingress-Ressourcen nutzen – nur eben nicht mehr mit dem Community-Controller, wenn du Upstream-Wartung willst. (Und perspektivisch verschiebt sich der Fokus ohnehin Richtung Gateway API.)

Zwei praxistaugliche Migrationspfade (plus eine strategische Option)

Im Kern hast du drei sinnvolle Richtungen:

1. Traefik: Migration „nebenbei" – durch Annotation-Kompatibilität und parallelen Betrieb
2. F5/NGINX Ingress Controller: „Nah am NGINX-Ökosystem", kommerziell getrieben, für viele Enterprises politisch leicht verkäuflich
3. Gateway API: Strategisch sauberer Zielzustand – aber selten der schnellste „EOL-Exit"

Entscheidungslogik in einer Tabelle

Traefik positioniert die Migration explizit so, dass bestehende Ingress-Ressourcen ohne Änderungen weiterlaufen, weil der Kubernetes Ingress NGINX Provider NGINX-Annotationen in Traefik-Konfiguration übersetzt. F5 beschreibt den eigenen Ingress Controller als NGINX-basierte Implementierung mit Annotation-/ConfigMap-Erweiterungen.

Der „weiche" Weg: Zero-Downtime-Migration von Ingress-NGINX zu Traefik

Traefik hat das Thema sehr operativ aufbereitet: Traefik neben NGINX installieren, Traffic schrittweise verlagern, NGINX entfernen – ohne Downtime.

Voraussetzung: Traefik-Version und Provider

Der Kubernetes Ingress NGINX Provider benötigt Traefik v3.6.2 oder neuer. Die Provider-Doku zeigt auch die zentralen Parameter (IngressClass, controllerClass, Namespaces, etc.).

Migrationsprinzip in einem Satz

Du betreibst zwei Controller parallel, die dieselben Ingress-Ressourcen „sehen". Danach verschiebst du Traffic kontrolliert – per DNS oder externem Load Balancer – und nimmst NGINX raus.

Schritt-für-Schritt: Parallelbetrieb, Verifikation, Traffic-Shift, Abschaltung

1) Traefik parallel installieren (ohne NGINX anzufassen)

Traefik wird zusätzlich ausgerollt – der entscheidende Schalter ist der Provider:

helm repo add traefik https://traefik.github.io/charts helm repo update helm upgrade --install traefik traefik/traefik \ --namespace traefik --create-namespace \ --set providers.kubernetesIngressNginx.enabled=true

Genau diese Aktivierung (providers.kubernetesIngressNginx.enabled=true) ist der Kern, damit Traefik deine bisherigen NGINX-Ingresses versteht.

Best Practice dabei: Nutze IngressClass-Steuerung, statt „alles im Cluster" zu scannen. Der Provider unterstützt gezielt ingressClass/controllerClass-Konfiguration.

2) Verifizieren, dass Traefik deine Ingresses korrekt bedient

Bevor du DNS änderst, testest du Traefik direkt über seine LoadBalancer-Adresse (ohne Nutzertraffic umzulenken). Traefik empfiehlt dafür Tests mit curl --connect-to, um Hostname/SNI beizubehalten.

Achte speziell auf:

• Redirects (HTTP→HTTPS)
• CORS-Header, Timeouts, Body-Size-Verhalten
• Session-Affinity / Cookie-Stickiness, falls genutzt
• gRPC/WebSockets, falls im Einsatz

3) Traffic schrittweise umstellen (zwei praxistaugliche Varianten)

Option A: DNS-basierte Migration (einfach, aber TTL-realistisch planen)

Du hängst Traefik zusätzlich in DNS (Round-Robin), beobachtest Verhalten, entfernst dann NGINX aus DNS.

Traefik weist dabei auf ein reales Problem hin: Manche Provider/ISPs respektieren TTL nicht zuverlässig – deshalb NGINX noch 24–48h weiterlaufen lassen, nachdem du es aus DNS genommen hast.

Option B: Externer Load Balancer mit Weighting (kontrollierter Rollout)

Wenn du davor ohnehin ein Global LB / Cloud LB / Traffic Steering hast, kannst du gewichtet verschieben (10% → 50% → 90% → 100%). Traefik skizziert das als kontrolliertere Alternative.

4) NGINX sauber entfernen – aber IngressClass erhalten

Ein häufig unterschätzter Punkt: Wenn Traefik deine bestehenden Ingress-Ressourcen über die NGINX-IngressClass beobachtet, darf die entsprechende IngressClass nicht einfach verschwinden. Traefik beschreibt das explizit als notwendigen Schritt: IngressClass preserven, dann deinstallieren.

Zusätzlich: Admission Webhooks entfernen, damit Ingress-Änderungen später nicht blockiert werden (wenn NGINX nicht mehr da ist).

TLS während der Migration: Der Klassiker, der Teams ausbremst

Wenn Traefik in der Verifikationsphase noch nicht „öffentlich" im DNS hängt, funktioniert Let’s Encrypt HTTP-01typischerweise nicht. Traefik nennt dafür pragmatische Wege:

• Bestehende Zertifikate über spec.tls.secretName weiterverwenden (cert-manager, externe PKI)
• Alternativ ACME DNS-01 Challenge für Traefik konfigurieren
• Nicht mit curl -k „grün testen" – das kaschiert echte Probleme

Praxis-Tipp: Wenn ihr cert-manager nutzt, ist das der angenehmste Pfad: Beide Controller greifen auf dieselben TLS-Secrets zu.

Was bedeutet „Annotation-Kompatibilität" in der Realität?

Traefik sagt nicht „wir sind NGINX", sondern: Wir übersetzen NGINX-Annotationen in Traefik-Konfiguration. Das ist goldwert für die Migration, aber du solltest im Blogpost ehrlich bleiben:

• Es gibt eine Liste unterstützter Annotationen und Verhaltensunterschiede.
• Bestimmte „Spezialtricks" aus ingress-nginx (z. B. sehr individuelle Snippets/Template-Hacks) sind naturgemäß schwieriger 1:1 abzubilden.

Wenn du diese Transparenz reinbringst, wirkt der Artikel nicht wie Marketing, sondern wie Plattform-Erfahrung.

Alternative: Beim NGINX-Ökosystem bleiben – mit dem F5/NGINX Ingress Controller

Für manche Organisationen ist „Controller-Wechsel" an sich politisch schwer. Dann ist die naheliegende Option: weg von Community-ingress-nginx, hin zum offiziell gepflegten NGINX Ingress Controller von F5/NGINX.

NGINX dokumentiert den Controller als Ingress-Implementierung mit Erweiterungen über Annotationen und ConfigMap und bewirbt ihn als langfristige Alternative nach dem Retirement.

Typische Positionierung für Entscheider:

• geringere „Tooling-Kultur-Umstellung" (NGINX bleibt im Stack-Narrativ)
• klarer Vendor-Owner für Lifecycle & Support
• aber: Produkt-/Lizenzfragen gehören früh geklärt

Strategischer Zielzustand: Gateway API (modernisieren, aber nicht als EOL-Notfallprojekt)

Die Gateway API ist für viele Plattformteams die langfristig sauberere Abstraktion (Rollenmodell, Delegation, Standardisierung). Aber: EOL-Migration ≠ Architektur-Modernisierung in einem Sprint.

Eine bewährte Vorgehensweise in Unternehmen:

1. EOL-Risiko entfernen (Controller wechseln, Betrieb stabilisieren)
2. Beobachten & standardisieren (Dashboards, Logs, SLOs, Policies)
3. Schrittweise auf Gateway API umstellen, dort wo es Mehrwert bringt (z. B. Teams/Namespaces delegieren, zentrale Policy, Multi-Tenant)

So bleibt die Migration lieferfähig, ohne dass sie zur „Plattform-Revolution" mutiert.

Migrations-Checkliste für Produktion

Fazit: Migration ist weniger ein Tool-Problem als ein Risiko- und Betriebsproblem

Ingress-NGINX endet im März 2026 – das ist kein Drama, aber ein klarer Lifecycle-Schnitt. Wenn du schnell und pragmatisch raus willst, ist Traefik mit dem Ingress-NGINX Provider ein sehr attraktiver Pfad, weil er bestehende Ingress-Manifeste und Annotationen weitgehend weiterträgt und den Parallelbetrieb sauber beschreibt. Wenn du im NGINX-Narrativ bleiben musst (Organisation, Compliance, Support), ist der F5/NGINX Ingress Controller die naheliegende Alternative.

Die eigentliche Erfolgskurve entsteht nicht durch „neuen Controller installieren", sondern durch:

• kontrollierten Traffic-Shift
• reproduzierbare Tests
• saubere TLS-Strategie
• Observability vor der Umstellung