Nach dem Ingress-NGINX-Support-Ende

Wenn Ihr Cluster den Traffic weiterhin über ingress-nginx leitet, betreiben Sie Software, für die niemand mehr zuständig ist. Das Repository wurde am 24. März 2026 archiviert. Es wird keine Releases mehr geben, keine Bugfixes und — das ist der entscheidende Teil — keine Sicherheitspatches, für keine Schwachstelle, nie wieder. An diesem Tag ist nichts kaputtgegangen, und genau das ist das Problem: Ihr Ingress läuft weiter, also hat Sie nichts zum Handeln gezwungen.

Das ist ein Migrationsleitfaden nach der Frist, nicht davor. Er zeigt, wie Sie Ihre Betroffenheit mit vier Befehlen messen, wie Sie das Ziel anhand von Belegen statt Bauchgefühl wählen, welche ingress-nginx-Eigenheiten bei der Übersetzung stillschweigend ihre Bedeutung ändern, und eine Rollout-Reihenfolge, mit der Sie den Traffic zurückholen können, wenn die neue Data Plane sich anders verhält als erwartet.

Was tatsächlich passiert ist — und was nicht

Die Chronologie ist kurz und sollte präzise wiedergegeben werden, weil viele Zweitquellen sie verzerrt haben. Kubernetes SIG Network und das Security Response Committee kündigten die Abkündigung am 11. November 2025 an. Am 29. Januar 2026 legten Steering Committee und SRC mit einer ungewöhnlich deutlichen gemeinsamen Erklärung nach: Wer nach der Abkündigung bei Ingress NGINX bleibe, setze sich und seine Nutzer Angriffen aus, und keine der verfügbaren Alternativen sei ein direkter Ersatz.^{[retire][steering]}

Die letzte Zeile wird am häufigsten missverstanden. Die Ingress-API ist nicht deprecated. Die Dokumentation stellt fest, dass sie generally available ist, dass das Projekt keine Pläne hat, sie zu entfernen, und dass sie schlicht eingefroren ist — keine weiteren Änderungen oder Updates. Ihre Ingress-Objekte unter networking.k8s.io/v1 sind gültiges Kubernetes und bleiben es. Gestorben ist ein bestimmter Controller, der sie liest.^[ingressdoc]

Was Sie erben, wenn Sie bleiben

Am klarsten lässt sich das Risiko über die Sicherheitsfixes bemessen, die das Projekt in seinen letzten Wochen ausgeliefert hat. Am 2. Februar 2026 — vier Tage nach der Steering-Erklärung, sieben Wochen bevor das Repository auf read-only gesetzt wurde — veröffentlichte das SRC vier Schwachstellen in ingress-nginx: CVE-2026-1580, CVE-2026-24512, CVE-2026-24513 und CVE-2026-24514. Die schwerwiegendsten wurden mit HIGH und 8,8 bewertet und in v1.13.7 sowie v1.14.3 behoben.^[advisory]

CVE-2026-24512 sollte man verinnerlichen. Über das Feld rules.http.paths.path eines Ingress ließ sich Konfiguration in NGINX injizieren — mit beliebiger Codeausführung im Kontext des Controllers und Offenlegung sämtlicher Secrets, die der Controller lesen kann; in einer Standardinstallation sind das alle Secrets im Cluster. Die Übergangsmaßnahme war ein Validating Admission Controller, der Ingress-Objekte mit dem Path Type ImplementationSpecific ablehnt. Beachten Sie, was diese Fehlerklasse vom Angreifer verlangt: die Fähigkeit, einen Ingress anzulegen. Jeder mit Schreibrechten in einem Namespace erfüllt das.^[cve24512]

Zwei weitere folgten, und sie machen das Argument erst vollständig. CVE-2026-3288, veröffentlicht am 9. März 2026 und mit HIGH 8,8 bewertet, war Konfigurationsinjektion über die Annotation rewrite-target — genau jene Annotation, vor der die Semantiktabelle weiter unten warnt — behoben in v1.13.8, v1.14.4 und v1.15.0. Dann CVE-2026-4342, veröffentlicht am 19. März 2026, mit 8,8 und identischem Vektor: kommentarbasierte Konfigurationsinjektion, erneut mit Codeausführung im Controller und clusterweiter Secret-Offenlegung. Behoben in v1.13.9, v1.14.5 und controller-v1.15.1. Also im letzten Release. Das Letzte, was dieses Projekt je ausgeliefert hat, war ein Sicherheitspatch — fünf Tage bevor das Repository read-only wurde. Was danach kommt, bekommt nichts mehr.^{[cve3288][cve4342][lastrel]}

Für die Obergrenze taugt der Präzedenzfall CVE-2025-1974 — „IngressNightmare“, März 2025, CVSS 9,8. Das Kubernetes-Projekt beschrieb ihn ohne Umschweife: Alles im Pod-Netzwerk hatte gute Chancen, das Cluster zu übernehmen, ganz ohne Zugangsdaten. Dafür gab es einen Patch. Für den nächsten nicht mehr.^[nightmare]

Bestehende Deployments laufen weiter — wenn Sie also nicht aktiv nachsehen, erfahren Sie unter Umständen erst von Ihrer Betroffenheit, wenn Sie bereits kompromittiert sind.^[steering]

Zur Größenordnung: Steering Committee und SRC geben an, dass rund 50 % der Cloud-native-Umgebungen auf den Controller angewiesen sind, unter Berufung auf interne Datadog-Untersuchungen. Behandeln Sie die Zahl als Richtwert, nicht als Messwert — der Datensatz ist nicht öffentlich und bildet von Datadog überwachte Umgebungen ab —, aber die Größenordnung deckt sich mit der projekteigenen Angabe von 2025: „über 40 % der Kubernetes-Cluster“. So oder so ist das keine Nebensächlichkeit.

Prüfen, ob Sie betroffen sind

Vor jeder Planung steht die Messung. Der erste Befehl ist der, den das Kubernetes-Projekt selbst veröffentlicht; die anderen drei sagen Ihnen, wie viel Arbeit tatsächlich vor Ihnen liegt — denn der Aufwand dieser Migration bemisst sich nicht an der Zahl der Ingress-Objekte, sondern an der Zahl der unterschiedlichen Annotationen dahinter.

# 1. The check the Kubernetes project itself publishes
kubectl get pods --all-namespaces \
  --selector app.kubernetes.io/name=ingress-nginx

# 2. Which controller image, and therefore which version, is actually running
kubectl get deploy -A -l app.kubernetes.io/name=ingress-nginx \
  -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.spec.template.spec.containers[0].image}{"\n"}{end}'

# 3. How much surface you have to translate: every Ingress bound to it
kubectl get ingress -A \
  -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}{"\t"}{.spec.ingressClassName}{"\n"}{end}'

# 4. The real cost driver - the annotations, ranked by how often you use them
kubectl get ingress -A -o json \
  | jq -r '.items[].metadata.annotations // {} | keys[]' \
  | grep -F 'nginx.ingress.kubernetes.io/' | sort | uniq -c | sort -rn

Der vierte Befehl ist die Schätzung. Ein Cluster mit sechzig Ingress-Objekten und vier Annotationen ist ein Nachmittag. Ein Cluster mit zwölf Ingress-Objekten und zweiundzwanzig Annotationen — darunter configuration-snippet — ist ein Projekt, und Sie wissen jetzt, warum.

Das Ziel festlegen, bevor Sie YAML anfassen

Es gibt drei ehrliche Optionen, und die richtige hängt davon ab, wie stark Sie tatsächlich vom Verhalten von ingress-nginx abhängen. Wichtig vor der Shortlist: Die einzigen Ingress-Controller, die Kubernetes als Projekt unterstützt und pflegt, sind der von AWS und der von GCE. Alles Übrige auf der dokumentierten Liste — Traefik, HAProxy, Contour, Kong, APISIX, Cilium, Higress, Istio und der Rest — stammt von Dritten. Und: kubernetes/ingress-nginx steht auf dieser Seite überhaupt nicht mehr.^[ctrldoc]

Wenn Sie den Gateway-API-Weg gehen: Das aktuelle Release ist v1.6.0, getaggt Ende Juni 2026 und am 3. August 2026 angekündigt. TCPRoute und UDPRoute sind damit von Experimental auf Standard in v1 aufgestiegen — neben Gateway, GatewayClass, HTTPRoute, GRPCRoute, TLSRoute, ListenerSet, ReferenceGrant und BackendTLSPolicy. Die v1alpha2-Varianten von TCPRoute und UDPRoute gelten seit v1.6 als deprecated und werden entfernt. Installieren Sie den aktuellen Patch, v1.6.1 vom 16. Juli 2026, nicht v1.6.0. Zu den Clusterversionen: Das Projekt nennt keine feste Untergrenze; erklärte Politik ist die Unterstützung der fünf jüngsten Kubernetes-Minor-Versionen. Prüfen Sie das gegen Ihren Cluster, statt einer Zahl aus einem Blogbeitrag zu vertrauen.^{[gw16][gw16rel][gw161][versioning]}

Eine strukturelle Änderung in v1.6 sollten Sie einplanen: Neue experimentelle Ressourcen liegen jetzt in einer eigenen API-Gruppe, gateway.networking.x-k8s.io, mit einem X-Präfix im Typnamen — XBackend, XMesh. Beim Aufstieg wird der Typ nach gateway.networking.k8s.io umbenannt und verliert das Präfix. Das ist ein bewusstes Signal: Beginnt der Kind, von dem Sie abhängen wollen, mit X, ist es keine Produktionszusage.^[gw16]

Entscheiden Sie anhand von Belegen. Das Gateway-API-Projekt veröffentlicht je Release Conformance-Berichte, die genau ausweisen, wie viele Extended Features jede Implementierung pro Route-Typ besteht. Diese Tabelle ist ein besseres Auswahlwerkzeug als jede Herstellerübersicht, diese eingeschlossen — sehen Sie in der Zeile der Version nach, die Sie betreiben wollen, nicht in der vom Vorjahr. Beachten Sie dabei: Nicht jede Implementierung reicht zu jedem Release einen Bericht ein. Eine fehlende Zeile heißt „kein Bericht für diese Version“, nicht „nicht konform“.^[conform]

Für den DACH-Kontext kommt eine Dimension hinzu, die in englischsprachigen Leitfäden meist fehlt: die Nachweispflicht. Ein internetseitig exponierter Ingress-Controller, für den es erklärtermaßen keine Sicherheitspatches mehr gibt, ist im Rahmen von NIS2, BSI IT-Grundschutz oder einer ISO-27001-Zertifizierung kein technisches Detail, sondern ein dokumentierbarer Prüfbefund — Schwachstellenmanagement ohne verfügbaren Patch-Pfad. Wer die Migration ohnehin planen muss, sollte den Zeitplan deshalb an die nächste Auditrunde koppeln und die Zwischenmaßnahmen (Einschränkung der Ingress-Erstellung, Entzug clusterweiter Secret-Rechte) schriftlich festhalten, statt sie nur umzusetzen.

Fünf Verhaltensweisen, die die Übersetzung nicht überleben

Hier scheitern Migrationen, und der Abschnitt lohnt sich auch dann, wenn das Ziel schon feststeht. ingress-nginx hat Verhaltensweisen angesammelt, die nie in der Ingress-Spezifikation standen, von denen Ihre Anwendungen inzwischen stillschweigend abhängen und die keine konforme Gateway-API-Implementierung reproduziert. Das Kubernetes-Projekt hat fünf davon eigens dokumentiert, um anderen diese Entdeckung zu ersparen.^[gotchas]

Am schmerzhaftesten ist in der Praxis der Trailing-Slash-Redirect, weil er nicht laut scheitert. Anfragen auf /api, die früher auf /api/ umgeleitet wurden, liefern jetzt einen 404 aus der Anwendung, und der Fehler taucht in den Logs Ihres Service auf statt am Edge — die erste Hypothese lautet also „Bug im Service“ und nicht „die Migration von gestern Nacht“.

ingress2gateway: was konvertiert wird — und was nicht

Es gibt einen offiziellen Konverter, und er ist deutlich besser geworden. ingress2gateway erreichte am 20. März 2026 als SIG-Network-Teilprojekt Version 1.0. Die wichtigste Änderung: Die Abdeckung von ingress-nginx-Annotationen stieg von drei auf über dreißig, darunter CORS, Backend-TLS, Regex-Matching und Path-Rewriting. Version 1.0 brachte zudem Integrationstests auf Controller-Ebene, die ein echtes ingress-nginx und einen echten Gateway-API-Controller in laufenden Clustern hochziehen und deren Laufzeitverhalten vergleichen, statt nur YAML zu diffen.^[i2gblog]

# Install the official converter (Go 1.25.5 or newer to build from source)
go install github.com/kubernetes-sigs/ingress2gateway@v1.0.0
# or: brew install ingress2gateway

# Convert a manifest on disk, without touching the cluster
ingress2gateway print --input-file ingress.yaml \
  --providers=ingress-nginx > gwapi.yaml

# Convert one namespace from a live cluster
ingress2gateway print --namespace shop \
  --providers=ingress-nginx > gwapi.yaml

# Convert everything, and keep the warnings - they are the migration backlog
ingress2gateway print --all-namespaces \
  --providers=ingress-nginx > gwapi.yaml 2> unsupported.log

Unterstützt werden neun Provider — ingress-nginx, nginx, traefik, kong, istio, apisix, cilium, gce und openapi — mit sechs Ausgabe-Emittern, darunter envoy-gateway und kgateway. Die Ausgabe zielt auf Gateway API v1.5.0. Was das Werkzeug Ihnen nicht abnimmt:^[i2g]

• configuration-snippet und server-snippet — nicht unterstützt, und es existiert keine Entsprechung. Beliebige NGINX-Direktiven waren genau die Designentscheidung, die das Kubernetes-Projekt als Ursache „unüberwindbarer technischer Schulden“ benannt hat. Wenn in Ihren Snippets Geschäftslogik steckt, muss diese in die Anwendung, in einen Filter oder in ein implementierungsspezifisches Policy-CRD wandern.^[retire]
• proxy-body-size — keine Entsprechung in der Gateway API. Konfigurieren Sie es stattdessen auf der Data Plane; damit wird es implementierungsspezifisch und ist nicht mehr portabel.
• proxy-read-timeout / proxy-send-timeout — Best-Effort-Abbildung auf timeouts.request, was nicht dasselbe ist. Unter Last neu messen, statt Parität anzunehmen.
• URL-Normalisierung — über die Standard-Gateway-API gar nicht konfigurierbar. Wenn Sie sich darauf verlassen haben, verlassen Sie sich auf die Data Plane und müssen es je Implementierung verifizieren.

Lesen Sie die Warnungen des Werkzeugs als Ihr Migrations-Backlog, nicht als Rauschen. Alles, was es auf stderr ausgibt, ist ein Verhalten, das es nicht übertragen konnte — und jedes davon ist ein Produktionsvorfall, der auf die DNS-Umstellung wartet.

Ingress und Gateway API im direkten Vergleich

Ein minimales, aber realistisches Beispiel: ein Hostname, TLS und ein Pfad, aufgeteilt zwischen API und Web-Frontend. Die Gegenüberstellung lohnt sich, weil die Gateway-API-Fassung länger ist — und diese Mehrlänge ist keine Zeremonie, sondern genau das Verhalten, das ingress-nginx implizit geliefert hat, jetzt ausgeschrieben.

Vorher — ein Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop-ingress
  namespace: shop
spec:
  ingressClassName: nginx
  tls:
    - hosts: [shop.example.com]
      secretName: shop-example-com-tls
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 8080
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80

Nachher — ein Gateway und zwei HTTPRoutes

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shop-gateway
  namespace: shop
spec:
  gatewayClassName: nginx          # must match an installed GatewayClass
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      hostname: shop.example.com
      allowedRoutes:
        namespaces:
          from: Same
    - name: https
      protocol: HTTPS
      port: 443
      hostname: shop.example.com
      tls:
        mode: Terminate
        certificateRefs:
          - group: ""              # empty string = core API group
            kind: Secret
            name: shop-example-com-tls
      allowedRoutes:
        namespaces:
          from: Same
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop-route
  namespace: shop
spec:
  parentRefs:
    - name: shop-gateway
      sectionName: https
  hostnames: [shop.example.com]
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: api-service
          port: 8080
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: web-service
          port: 80
---
# ingress-nginx redirected HTTP to HTTPS for you. Gateway API does not.
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop-route-ssl-redirect
  namespace: shop
spec:
  parentRefs:
    - name: shop-gateway
      sectionName: http
  hostnames: [shop.example.com]
  rules:
    - filters:
        - type: RequestRedirect
          requestRedirect:
            scheme: https
            statusCode: 308

Drei Punkte fallen auf. sectionName bindet die Route an einen bestimmten Listener; so halten Sie HTTP- und HTTPS-Verhalten getrennt. allowedRoutes ist die Rollentrennung, die der Ingress-API immer gefehlt hat: Ein Plattformteam besitzt das Gateway und entscheidet, welche Namespaces sich anhängen dürfen, während die Anwendungsteams ihre HTTPRoutes besitzen. Und das dritte Objekt existiert nur, um einen Redirect nachzubilden, den ingress-nginx standardmäßig ausgeführt hat — was die Migration insgesamt ganz gut zusammenfasst.^[gwapi]

Eine Umstellung, die Sie zurücknehmen können

Die nützlichste Eigenschaft dieser Migration: Beide Controller können gleichzeitig laufen. Es sind verschiedene Objekte, die verschiedene Ressourcen beobachten, hinter verschiedenen Load Balancern. Nichts zwingt zu einer Big-Bang-Umstellung — also machen Sie keine.

1. Neuen Controller neben dem alten installieren. Eigene GatewayClass, eigener Namespace, eigener LoadBalancer-Service und eigene externe Adresse. Der Traffic läuft weiter über ingress-nginx.
2. Konvertieren und prüfen. ingress2gateway gegen einen Namespace laufen lassen, die Warnungen lesen und die nicht übersetzbaren Annotationen von Hand nacharbeiten. Die Ausgabe nicht ungelesen anwenden.
3. Gateway-API-Objekte anwenden, mit denselben Hostnames. Für Nutzer ändert sich noch nichts — der neue Controller hat eine eigene IP, und kein DNS-Eintrag zeigt darauf.
4. Beide Edges direkt vergleichen, mit --resolve, Anfrage für Anfrage: Statuscodes, Redirect-Ziele, Header und speziell die Trailing-Slash- und Regex-Fälle. Dieser Schritt fängt die fünf oben genannten Verhaltensweisen ab.
5. DNS schrittweise umstellen — Eintrag mit niedriger TTL, gewichtete Policy oder zuerst ein unkritischer Hostname. ingress-nginx weiter ausliefern lassen, bis der neue Edge echten Traffic über eine Lastspitze getragen hat.
6. Bewusst abbauen. ingress-nginx-Deployment, Service, IngressClass und ValidatingWebhookConfiguration entfernen. Ein zurückgelassener Admission-Webhook ist der Weg zu einem kaputten Cluster Wochen später.

# Install the Standard channel CRDs (server-side apply, as the project documents)
kubectl apply --server-side -f \
  https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.6.1/standard-install.yaml

# The Gateway must be Programmed before you move any traffic to it
kubectl get gateway shop-gateway -n shop \
  -o jsonpath='{.status.conditions[?(@.type=="Programmed")].status}{"\n"}'

# Every parentRef must be Accepted, and every backendRef ResolvedRefs.
# Nested ranges keep each condition paired with its own status.
kubectl get httproute shop-route -n shop -o jsonpath='{range .status.parents[*]}{.controllerName}{"\t"}{range .conditions[*]}{.type}={.status}{" "}{end}{"\n"}{end}'

# Compare old and new on the same request, before DNS moves.
# A cloud load balancer publishes either .ip or .hostname - AWS uses .hostname,
# so --connect-to is used instead of --resolve: it accepts both.
OLD=$(kubectl get svc -n ingress-nginx ingress-nginx-controller \
  -o jsonpath='{.status.loadBalancer.ingress[0].ip}{.status.loadBalancer.ingress[0].hostname}')
NEW=$(kubectl get gateway shop-gateway -n shop \
  -o jsonpath='{.status.addresses[0].value}')
for edge in "$OLD" "$NEW"; do
  curl -sS -o /dev/null -w "$edge  %{http_code}  %{redirect_url}\n" \
    --connect-to "shop.example.com:443:$edge:443" https://shop.example.com/api
done

Achten Sie im zweiten Befehl auf die Condition Programmed. Ein Gateway, das existiert, ist noch kein Gateway, das ausliefert; die Status-Conditions sind der Vertrag, und sie zu prüfen ist billiger, als den Unterschied während der DNS-Umstellung zu entdecken.

ingress-nginx, NGINX Ingress, NGINX Gateway Fabric

Drei getrennte Projekte, ähnliche Namen — und eine echte Quelle von Fehlentscheidungen genau während dieser Migration. Manche migrieren von ingress-nginx auf „NGINX Ingress“ in dem Glauben, etwas geändert zu haben, und wundern sich später — oder schreiben NGINX komplett ab, weil sie annehmen, alle drei seien gemeinsam gestorben.

Das Kubernetes-Projekt sah sich genötigt, es explizit hinzuschreiben: Beide nutzen NGINX als Data Plane, sind ansonsten aber nicht miteinander verwandt. Der Wechsel vom Community-Controller zu dem von F5 ist eine echte Migration mit eigener Annotationsübersetzung — keine Umbenennung.^[gotchas]

Was ich diese Woche tun würde

Falls Sie noch nicht begonnen haben: Führen Sie heute die vier Erkennungsbefehle aus, denn die Zahl der Annotationen ist die einzige Kennzahl, die Ihnen sagt, ob das ein Nachmittag oder ein Quartal wird. Lautet die Antwort „ein Nachmittag“, erledigen Sie es diese Woche und tragen das Risiko nicht länger. Lautet sie „ein Quartal“, ist der sinnvolle Schritt trotzdem, jetzt einen zweiten Controller parallel zu installieren und einen unkritischen Hostname zu migrieren — denn bei der ersten Migration lernen Sie, welche Ihrer Annahmen in Wahrheit ingress-nginx-Verhalten waren.

Die übergeordnete Lehre habe ich schon in langweiligen Cloud-Architekturen beschrieben: Am gefährlichsten sind die Komponenten, an die niemand denkt — gerade weil sie seit Jahren funktionieren. Ein Ingress-Controller, gepflegt von ein bis zwei Freiwilligen, vor der halben Cloud-native-Welt, war lange vor der Archivierung eine Risikokonzentration. Es lohnt sich zu prüfen, was in Ihrem Stack sonst noch diese Form hat — und zu fragen, wie in wann man Kubernetes nicht einsetzen sollte, ob die Plattform die operative Angriffsfläche wert ist, die sie kostet.

Häufige Fragen

Kann ich ingress-nginx vorerst gefahrlos weiterbetreiben?

Es läuft, und es wird weiterlaufen. Aber es wird nie wieder einen Sicherheitspatch erhalten — und man sollte sich ansehen, was das letzte Release tatsächlich war: controller-v1.15.1 war der Fix für CVE-2026-4342, eine Konfigurationsinjektion bis hin zu Codeausführung im Controller und Offenlegung clusterweiter Secrets, ausgeliefert am selben Tag wie der Hinweis und fünf Tage bevor das Repository read-only wurde. Das war der sechste Fehler dieser Art in sieben Wochen. Für den nächsten gibt es keinen Fix. Wenn Sie es noch einige Wochen betreiben müssen, schränken Sie mindestens ein, wer Ingress-Objekte anlegen darf, entziehen Sie dem Controller den clusterweiten Secret-Zugriff, falls Ihre Installation ihn gewährt, und exponieren Sie den Admission-Webhook nicht.

Ist die Kubernetes-Ingress-API ebenfalls deprecated?

Nein, und das ist das häufigste Missverständnis. Die Ingress-API ist generally available, unterliegt den normalen GA-Stabilitätsgarantien, und das Kubernetes-Projekt hat erklärt, keine Pläne zur Entfernung zu haben. Sie ist eingefroren: keine Weiterentwicklung. Abgekündigt wurde nur der Community-NGINX-Controller, nicht die API, die er implementiert.

Was ist der Unterschied zwischen ingress-nginx und NGINX Ingress Controller?

Es sind verschiedene Projekte verschiedener Organisationen. kubernetes/ingress-nginx wurde von der Kubernetes-Community gepflegt und ist archiviert. nginx/kubernetes-ingress ist der NGINX Ingress Controller von F5 und wird aktiv entwickelt. In der Formulierung des Kubernetes-Projekts: Beide nutzen NGINX als Data Plane, sind ansonsten aber nicht verwandt. Der Wechsel von einem zum anderen ist eine echte Migration, keine Umbenennung.

Kann ingress2gateway mein Cluster automatisch migrieren?

Teilweise. Version 1.0 deckt über dreißig ingress-nginx-Annotationen ab, vorher waren es drei, und ist der richtige Ausgangspunkt. Aber configuration-snippet hat keine Entsprechung und wird nicht unterstützt, proxy-body-size hat kein Gateway-API-Äquivalent, Proxy-Timeouts werden nur nach bestem Bemühen abgebildet, und URL-Normalisierung lässt sich gar nicht ausdrücken. Lesen Sie alles, was auf stderr erscheint — diese Ausgabe ist Ihre verbleibende Handarbeit.

Auf Gateway API umsteigen oder nur den Ingress-Controller wechseln?

Der Controller-Wechsel ist schneller und erhält Ihre bestehenden Objekte, aber Sie landen auf einer eingefrorenen API und müssen trotzdem jede Annotation in einem neuen Dialekt neu ausdrücken — Sie werden das also vermutlich noch einmal tun. Die Gateway API ist der größere Umbau, aber dort findet die Entwicklung statt, und sie bringt Rollentrennung zwischen dem Plattformteam, dem das Gateway gehört, und den Anwendungsteams, denen ihre Routen gehören. Große Bestände einfacher Ingress-Objekte sprechen für den Controller-Wechsel; von mehreren Teams geteilte Edges für die Gateway API.

Welche Gateway-API-Implementierung soll ich wählen?

Wählen Sie anhand der veröffentlichten Conformance-Berichte statt anhand von Marketingseiten. Das Gateway-API-Projekt weist je Release exakt aus, wie viele Extended Features jede Implementierung für HTTPRoute, GRPCRoute und TLSRoute besteht. Prüfen Sie den Bericht zu der Version, die Sie tatsächlich betreiben wollen, vergewissern Sie sich, dass die Implementierung genau die Features unterstützt, in die Ihre Annotationen übersetzt wurden, und dass sie auf Ihrer Plattform unterstützt wird.

Muss ich Kubernetes aktualisieren, bevor ich die Gateway API installiere?

Das Projekt nennt keine feste Mindestversion von Kubernetes; erklärte Politik ist die Unterstützung der fünf jüngsten Minor-Versionen — prüfen Sie diese Politik gegen Ihren Cluster statt einer Zahl aus einem Blogbeitrag. Installieren Sie die CRDs des Standard-Kanals aus dem aktuellen Patch-Release — v1.6.1 vom 16. Juli 2026 — per Server-Side Apply, so wie es das Projekt dokumentiert. Beim Experimental-Kanal sind die CRDs ohnehin zu groß für ein clientseitiges kubectl apply; und experimentelle Typen tragen jetzt ein X-Präfix in einer eigenen API-Gruppe, genau damit Sie nicht versehentlich Produktion darauf bauen.

Dieselbe Disziplin gilt für die darunterliegende Kryptografie: Post-Quanten-SSH und -TLS beschreibt, was auf den Verbindungen zu prüfen ist, auf die diese Systeme angewiesen sind.

Quellen

Jede Aussage oben ist auf eine dieser Quellen zurückführbar. Ausschließlich primäre und offizielle Quellen: Blogbeiträge und Dokumentation des Kubernetes-Projekts, Repository-Zustand, Sicherheitshinweise und die Gateway-API-Spezifikation.

1. Kubernetes blog — Ingress NGINX Retirement: What You Need to Know (11 Nov 2025)
2. Kubernetes blog — Ingress NGINX: Statement from the Steering and Security Response Committees (29 Jan 2026)
3. Kubernetes blog — Before You Migrate: Five Surprising Ingress-NGINX Behaviors You Need to Know (27 Feb 2026)
4. GitHub — kubernetes/ingress-nginx (public archive, read-only since 24 Mar 2026)
5. GitHub — ingress-nginx controller-v1.15.1, the final release (19 Mar 2026)
6. Kubernetes Security Response Committee — [Security Advisory] Multiple issues in ingress-nginx (2 Feb 2026)
7. kubernetes/kubernetes#136678 — CVE-2026-24512, configuration injection via the Ingress path field
8. kubernetes/kubernetes#137560 — CVE-2026-3288, configuration injection via the rewrite-target annotation
9. kubernetes/kubernetes#137893 — CVE-2026-4342, comment-based configuration injection (fixed by the final release)
10. Kubernetes blog — Ingress-nginx CVE-2025-1974: What You Need to Know (24 Mar 2025)
11. Kubernetes documentation — Ingress (the API is generally available and frozen)
12. Kubernetes documentation — Ingress Controllers
13. Gateway API — API overview and channel status
14. Kubernetes blog — Gateway API v1.6: TCPRoute and UDPRoute Graduate to Standard (3 Aug 2026)
15. GitHub — Gateway API v1.6.0 release notes
16. GitHub — Gateway API v1.6.1, the current patch release (16 July 2026)
17. Gateway API — v1.6 conformance reports by implementation
18. GitHub — kubernetes-sigs/ingress2gateway
19. Kubernetes blog — Announcing Ingress2Gateway 1.0: Your Path to Gateway API (20 Mar 2026)
20. GitHub — nginx/kubernetes-ingress, the F5 NGINX Ingress Controller (a different project)
21. GitHub — nginx/nginx-gateway-fabric, F5's Gateway API implementation
22. Gateway API — versioning, release channels and graduation criteria