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:
- Traefik: Migration „nebenbei" – durch Annotation-Kompatibilität und parallelen Betrieb
- F5/NGINX Ingress Controller: „Nah am NGINX-Ökosystem", kommerziell getrieben, für viele Enterprises politisch leicht verkäuflich
- Gateway API: Strategisch sauberer Zielzustand – aber selten der schnellste „EOL-Exit"
Entscheidungslogik in einer Tabelle
| Ziel | Wann es passt | Vorteil | Typischer Haken |
|---|---|---|---|
| Traefik (Ingress-NGINX Provider) | Wenn du schnell raus willst, ohne Manifeste neu zu schreiben | Übersetzt NGINX-Annotationen automatisch; Zero-Downtime-Guide | Unterschiede in Verhalten/Edge-Cases müssen getestet werden |
| F5/NGINX Ingress Controller | Wenn „NGINX bleiben" politisch/operativ wichtig ist | Offiziell gepflegter Controller; Annotationen & ConfigMap-Erweiterungen | Produkte/Features teils an F5/NGINX-Ökosystem gekoppelt |
| Gateway API | Wenn du ohnehin Plattform-Standardisierung vorantreibst | Rollen/Delegation, bessere Erweiterbarkeit | Migration meist kein Drop-in, braucht Design-Entscheidungen |
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.secretNameweiterverwenden (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:
- EOL-Risiko entfernen (Controller wechseln, Betrieb stabilisieren)
- Beobachten & standardisieren (Dashboards, Logs, SLOs, Policies)
- 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
| Bereich | Was du prüfen solltest | Warum es wichtig ist |
|---|---|---|
| HTTP Routing | Pfade, pathType, host-basierte Regeln |
Kleine Semantik-Details machen große Effekte |
| Redirects | HTTP→HTTPS, HSTS | Bricht sonst Login-Flows und API-Clients |
| CORS | Header, Origins, Credentials | Frontends merken es sofort |
| Timeouts/Body Size | Uploads, APIs, Webhooks | Häufige Fehlerquelle nach Cutover |
| Sticky Sessions | Cookie-Affinity | Besonders bei Legacy-Apps relevant |
| gRPC/WebSockets | Upgrade/HTTP2 Verhalten | Monitoring zeigt's oft erst unter Last |
| Observability | Access Logs, Metrics, Tracing | Ohne Baseline keine sichere Umstellung |
| Rollback | DNS zurück / Weighting zurück | Muss geübt sein, nicht nur gedacht |
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