Tschüss Ingress-nginx, hallo Gateway API

Jahrelang war das erste, was ich auf fast jedem neuen Kubernetes Cluster installierte, ingress-nginx. Vor den Apps, vor der Überwachung, vor allem Interessanten. Es war die Haustür. Der Verkehr kam herein, Ingress-Ninx schickte ihn an den richtigen Ort, und ich musste selten darüber nachdenken.

Die Haustür ist offiziell nicht mehr gepflegt. Im November 2025 gab das Kubernetes-Projekt bekannt, dass Ingress-Ninx aus dem Betrieb gehen würde, wobei die Best-Effort-Wartung nur bis März 2026 stattfinden würde. Das Datum ist vorbei. Wenn Sie es noch laufen lassen, und viele Cluster laufen, dann ist das hier, was das bedeutet und wie ich aussteigen würde.

Was wirklich passiert ist

ingress-nginx war ein Gemeinschaftsprojekt, das jahrelang von einer sehr kleinen Gruppe Freiwilliger in ihrer Freizeit am Leben gehalten wurde. Das ist keine Kritik. Es ist die unbequeme Wahrheit hinter vielen der Software, von der wir alle abhängen.

Die Sicherheitskräfte haben es noch schlimmer gemacht. Im März 2025 wird eine Reihe von schweren Schwachstellen, EinbruchNightmare zeigte, dass ein Fehler in Ingress-Ningx im schlimmsten Fall einen Angreifer über einen ganzen Cluster verfügen lassen könnte. Solche Dinge richtig zu reparieren, braucht Zeit und Leute, die das Projekt einfach nicht hatte. Das Kubernetes SIG Network und das Security Response Committee haben also ehrlich entschieden: sie zu beenden. Ein geplantes Nachfolgerprojekt, das InGate heißt, ist nie weit genug vorangekommen und wird ebenfalls eingestellt.

Zwei Dinge sind leicht zu verwechseln, also lass mich klar sein:

• Der Ingress-Ninginx-Controller ist ausgeschaltet. Keine neuen Versionen, keine Bugfixes, keine Sicherheits-Patches. Die Repositories sind nur lesbar.
• Die Kubernetes Ingress API ist nicht. Die Ingress Die Ressource funktioniert noch. Es ist einfach gefroren: es kommen keine neuen Funktionen.
• Der kommerzielle NGINX Ingress Controller von F5 ist ein anderes Produkt. Der gleiche Familienname, ein anderer Code, immer noch erhalten.

Muss ich in Panik geraten?

- Nein, nicht wirklich. Ihr Cluster ist nicht kaputt, als die Wartung vorbei war. Die bestehenden Installationen werden fortgesetzt, und die Bilder und Helm-Charts sind noch verfügbar.

Aber denken Sie darüber nach, was diese Komponente ist. Es ist das einzige Ding in deinem Cluster, das direkt ins Internet geht. Es analysiert jede Anfrage von Fremden. Und ab jetzt, wenn die nächste Schwachstelle gefunden wird, wird sie niemand reparieren. Das ist kein "eines Tages" Problem. Es ist ein Problem dieses Quartals.

Unpatched Software am Rand des Clusters auszuführen, ist, als würde man die Haustür nicht verschlossen lassen, weil sie noch nie ausgeraubt wurde.

Zuerst müssen Sie herausfinden, ob Sie überhaupt betroffen sind. Dieser Befehl, aus der offiziellen Ankündigung, listet alle Ingress-Ningx-Pods im Cluster auf:

kubectl get pods --all-namespaces \
  --selector app.kubernetes.io/name=ingress-nginx

Wenn das nichts bringt, kannst du dich entspannen und vielleicht zum Ende springen. Wenn es Kapseln zurückbringt, lesen Sie weiter.

Gateway-API, in einfachen Worten

Die Gateway API ist der offizielle Nachfolger von Ingress. Es ist auch nicht neu: Der Kern wurde bereits 2023 stabil, und heute unterstützt ihn fast jedes große Netzwerkprojekt und jeder Cloud-Anbieter.

Die größte Veränderung ist, dass ein großes Objekt zu einigen kleineren wird, jedes im Besitz der richtigen Person:

• GatewayClass wird nicht mehr verwendet: welche Implementierung den Datenverkehr durchführt, z. B. Envoy Gateway oder Cilium. Normalerweise wird es einmal vom Plattformteam eingerichtet.
• Durchgang: der eigentliche Einreisepunkt. Welche Ports, welche Hostnamen, welche TLS-Zertifikate. Eigentum von dem, der das Cluster leitet.
• HTTP-Route: die Routing-Regeln für eine App. "Senden Sie /api Eigentum des App-Teams, in ihrem eigenen Namespace.

Bei Ingress wurde alles in eine Ressource gepresst, und alles, was die Spezifikation nicht abdeckte, wurde in Anmerkungen versteckt. Wer einen Eintritt mit 15 gesehen hat, nginx.ingress.kubernetes.io/... Linie weiß, was ich meine. Diese Anmerkungen funktionierten nur mit einem Controller, also hielt "Portable Kubernetes" an der Haustür an.

	Eintritt	Gateway-API
Struktur	Eine Ressource macht alles.	Getrennte Teile für Plattform- und App-Teams
Erweiterte Funktionen	Datenverarbeitungsanlagen	Eingebettet in die Spezifikation: Header-Matching, Traffic-Split, Weiterleitungen
Protokoll	HTTP und HTTPS	HTTP, gRPC, TLS und TCP/UDP mit einigen Implementierungen
Übertragbarkeit	Niedrig, wenn Anmerkungen hereinkommen	Viel besser: Das gleiche YAML funktioniert über Implementierungen hinweg
Zukunft	Froren	Wo die neue Arbeit stattfindet

So sieht es in der Praxis aus. Zuerst das Gateway, das einmal vom Plattformteam eingerichtet wurde:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: web
  namespace: infra
spec:
  gatewayClassName: eg          # e.g. Envoy Gateway
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    hostname: "*.example.com"
    tls:
      mode: Terminate
      certificateRefs:
      - name: example-com-tls
    allowedRoutes:
      namespaces:
        from: All               # tighten this with a label selector later

Dann fügt jedes App-Team seine eigene Route an, in seinem eigenen Namespace:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop
  namespace: shop
spec:
  parentRefs:
  - name: web
    namespace: infra
  hostnames: ["shop.example.com"]
  rules:
  - matches:
    - path: { type: PathPrefix, value: /api }
    backendRefs:
    - name: shop-api
      port: 8080

Das App-Team berührt nie das Gateway, und das Plattformteam muss nie eine Routingänderung für den Dienst eines anderen genehmigen. Diese Trennung gefällt mir am meisten. Es passt zu der Art und Weise, wie Teams tatsächlich arbeiten.

Die Wahl des Ersatzs

Die Gateway-API ist nur eine Spezifikation. Du brauchst immer noch etwas, um es zu laufen. Die gute Nachricht ist , dass es viele solide Optionen gibt:

• Gesandter-GatewayEine saubere, fokussierte Wahl, wenn man nur eine gute Haustür will. Mein Standardvorschlag für die meisten Teams.
• Zilium: ist sinnvoll, wenn Sie bereits Cilium für Cluster-Netzwerke verwenden. Eine Komponente weniger.
• - Ich weiß.: wenn Sie bereits ein Service Mesh betreiben oder planen.
• NGINX Gateway-Fabrik oder Verkehr: wenn Ihr Team in der Nähe dessen bleiben will, was es bereits weiß.
• Das Gateway Ihres Cloud-Anbieters: GKE, AWS und Azure haben alle verwaltete Optionen, was bedeutet, dass es eine Sache weniger zu patchen gibt.

Verbringe keine Wochen damit, Benchmarks zu vergleichen. Für die meisten Cluster ist die ehrliche entscheidende Frage: Was versteht mein Team bereits, und was werden wir in drei Jahren noch gerne beibehalten?

Wie ich mich bewegen würde, Schritt für Schritt

Der Trick ist, nie einen großen Wechsel zu machen. Fahren Sie beide Seite an Seite, bewegen Sie den Verkehr langsam und halten Sie einen Weg zurück.

1. Machen Sie einen Bilanz. Liste alle eingegangenen Eingaben und, noch wichtiger, jede verwendete Anmerkung auf. Diese Zeile gibt Ihnen eine schnelle Zählung:

bash kubectl get ingress -A -o yaml \ | grep -o 'nginx.ingress.kubernetes.io/[a-z-]*' \ | sort | uniq -c | sort -rn

Die Anmerkungen sind, wo sich die echte Arbeit versteckt.

2. Installieren Sie die neue Implementierung neben der alten. Es hat seinen eigenen Lastbalancer und seine eigene IP. Für die Nutzer ändert sich noch nichts.

3. Umschalten mit Ingress2 Gateway. Das eigene Tool des Kubernetes-Projekts erreichte im März 2026 die Version 1.0. Es liest Ihre vorhandenen Ingress-Ressourcen und schreibt die Gateway-API-Äquivalente:

bash ingress2gateway print --providers=ingress-nginx \ --all-namespaces -o yaml > gateway-resources.yaml

Betrachten Sie die Ergebnisse als einen ersten Entwurf, nicht als die endgültige Antwort. Überprüfen Sie es, wie Sie eine Anfrage zur Abholung überprüfen würden.

4. Beheben Sie mit der Hand, was das Werkzeug nicht kann. Benutzerdefinierte Snippets, Authentifizierung, Geschwindigkeitsbegrenzung, ungewöhnliche Umschriften und Regex-Wege erfordern normalerweise manuelle Arbeit. Viele dieser werden zu umsetzungsbezogenen Richtlinien anstelle von Anmerkungen.

5. Testen Sie, bevor sich DNS ändert. Richten Sie Anfragen direkt an die neue IP und überprüfen Sie, ob alles funktioniert:

bash curl --resolve shop.example.com:443:NEW_GATEWAY_IP \ https://shop.example.com/api/health

6. Bewegen Sie den Verkehr allmählich. Senken Sie Ihre DNS TTLs einen Tag vorher, dann bewegen Sie einen Hostnamen nach dem anderen, beginnend mit dem am wenigsten wichtigen. Ingress-Ningx läuft, also ist das Zurückrollen nur eine DNS-Änderung.

7. - Was ist los? Sobald alles für eine Weile ruhig läuft, entfernen Sie Ingress-Ninx und seine Ingress-Ressourcen. Vergessen Sie nicht die Tools: cert-manager und ExternalDNS unterstützen beide Gateway API, müssen aber dafür konfiguriert werden.

Was beißt

Ein paar Dinge sind leicht zu unterschätzen:

• Kommentar zum Stück. Wenn jemand die Roh-NGINX-Konfiguration in configuration-snippet Vor Jahren gab es keine direkte Übersetzung. Zuerst musst du herausfinden, wofür es überhaupt war. Manchmal ist die Antwort: "Nichts mehr".
• Er schreibt es um. rewrite-target Mit Regex-Capture-Gruppen wird nicht eins zu eins abgebildet. Testen Sie jeden umgeschriebenen Pfad.
• Kleine Verhaltensunterschiede. Standard-Timeouts, Körpergrößenbeschränkungen und Header-Handling unterscheiden sich zwischen den Implementierungen. Dinge, die "nur funktioniert haben", können plötzlich eine 413 oder eine Auszeit zurückgeben.
• Wer was besitzt. Das neue Modell teilt die Verantwortung zwischen den Teams. Das ist großartig, aber nur, wenn Sie sich darauf geeinigt haben, wer der Besitzer des Gateways ist und welche Namespaces Routen daran anbringen dürfen.

Was würde ich jemandem sagen, ab heute

Wenn Sie einen neuen Cluster erstellen, installieren Sie Ingress-nginx nicht und schreiben Sie auch keine neuen Ingress-Ressourcen. Beginnen Sie mit der Gateway API vom ersten Tag an. Die Konzepte dauern einen Nachmittag, um sie zu lernen, und Sie müssen diese Migration nie machen.

Und wenn Sie Kubernetes lernen, ist das eine gute Lektion an sich. Das beliebteste Projekt seiner Art, das von fast allen benutzt wird, wurde von einer Handvoll müder Freiwilliger gepflegt. Bevor man auf etwas baut, lohnt es sich zu fragen, wer es tatsächlich am Leben hält.

Ist es also die Mühe wert?

Ehrlich gesagt, ja, und nicht nur wegen der Sicherheit. Die Gateway-API ist einfach das bessere Modell. Sauberes YAML, weniger magische Anmerkungen, eine klare Trennung zwischen Plattform- und App-Teams und Funktionen, die früher Hacks benötigten, sind jetzt integriert.

Der Ruhestand zwingt uns zu einem Schritt, den die meisten von uns sowieso machen sollten. Besser, es jetzt ruhig zu tun, als es in Eile zu tun, am Tag, an dem die nächste große Schwachstelle bekannt gegeben wird.

Meine Meinung: Die Haustür hat sich geändert, aber der Job nicht. Planen Sie es, laufen Sie beide Seite an Seite, bewegen Sie sich langsam und halten Sie einen Weg zurück.

Desly