Kubernetes 1.36: Ingress-NGINX ist tot, migrieren Sie zur Gateway API

CNCF Cloud Native Landscape: The Practical Guide

A practical guide to the CNCF Cloud Native Landscape — the tools and categories that actually matter for building production infrastructure.

Etwa die Hälfte aller Kubernetes-Cluster wurde von Ingress-NGINX betrieben. Am 24. März 2026 wurde es in den Read-Only-Modus versetzt. Keine Bugfixes mehr, keine Sicherheitspatches.

Was ist passiert

Die Einstellung war nicht plötzlich. Im November 2025 gaben das Kubernetes SIG Network und das Security Response Committee bekannt, dass der ingress-nginx Controller bis März 2026 in eine Best-Effort-Wartung übergehen würde, nach der die gesamte Entwicklung eingestellt würde. In der Ankündigung wurde eine nicht mehr tragbare Lücke bei den Maintainern angeführt: Trotz Millionen von Deployments wurde das Projekt von ein oder zwei Maintainern aufgewendet, die in ihrer Freizeit daran arbeiteten. Wiederholte Aufrufe nach Mitwirkenden blieben unbeantwortet.

Am 29. Januar 2026 veröffentlichten das Steering Committee und das Security Response Committee eine gemeinsame Erklärung, in der gewarnt wurde, dass etwa 50 Prozent der Cloud-Native-Umgebungen vom Controller abhängig seien. Die Erklärung war deutlich: „Wir können die Schwere dieser Situation oder die Bedeutung des Beginns der Migration zu Alternativen wie der Gateway API nicht genug betonen.“ Am 2. Februar wurden vier CVEs mit hoher Schwerestufe gegen ingress-nginx bekannt gegeben, was das Risiko unterstrich, nicht gewartete Software im L7-Datenpfad zu betreiben.

Am 24. März 2026 wurde das kubernetes/ingress-nginx Repository archiviert und in die Organisation kubernetes-retired verschoben. Bestehende Deployments funktionieren weiterhin, und Helm-Charts sowie Container-Images bleiben verfügbar, aber es wird keine weiteren Releases jeglicher Art geben.

Eine wichtige Klarstellung: Die Kubernetes Ingress API selbst wird nicht entfernt. Sie bleibt GA und ist feature-frozen. Was eingestellt wurde, ist der Community-ingress-nginx-Controller. Der kommerzielle Controller von F5/NGINX Inc. ist ein separates Projekt und ist nicht betroffen.

Warum Gateway API

Die Ingress API wurde in Kubernetes 1.19 eingeführt und hat dem Ökosystem gut gedient, aber ihr Design sammelte Einschränkungen an, die ohne die Zerstörung der Abwärtskompatibilität nicht mehr zu beheben waren. Die Gateway API ersetzt diese Einschränkungen durch eine bewusst erweiterbare Architektur.

Typisierte CRDs ersetzen den „Annotation Sprawl“. Ingress-nginx stützte sich auf Dutzende von Annotationen, um Verhaltensweisen zu konfigurieren, die die Basis-API nicht ausdrücken konnte: CORS-Richtlinien, Backend-TLS, Regex-Pfadmatching, Rate Limiting, Canary-Deployments. Jede Annotation war controllerspezifisch, was Konfigurationen nicht portabel und schwer validierbar machte. Die Gateway API kodiert diese Verhaltensweisen als First-Class-Felder in stark typisierten Ressourcen.

Die dreischichtige Rollentrennung ist die zentrale architektonische Verbesserung. GatewayClass ist die Ressource auf Infrastrukturebene, analog zu einer StorageClass. Plattform-Teams definieren sie einmalig, um festzulegen, welche Controller-Implementierung verwendet werden soll. Gateway bindet Listener an Adressen. Cluster-Operatoren erstellen Gateway-Ressourcen, um Load Balancer bereitzustellen und die TLS-Terminierung zu konfigurieren. HTTPRoute, TLSRoute, GRPCRoute und andere Route-Typen definieren das Routing auf Anwendungsebene. Anwendungsentwickler besitzen diese Ressourcen und können sie an Gateways anhängen, ohne die Infrastrukturkonfiguration zu berühren. Diese Trennung bildet reale organisatorische Grenzen sauber ab und ermöglicht eine native RBAC-Durchsetzung.

Multi-Protokoll-Unterstützung ist von Anfang an integriert. Während Ingress nur HTTP und HTTPS verarbeiten konnte, bietet die Gateway API native Route-Typen für HTTP, gRPC, TCP, UDP und TLS-Passthrough. Dies macht separate ConfigMap-Hacks oder Sidecar-Proxys für den Umgang mit Nicht-HTTP-Traffic überflüssig.

Gateway API Ressourcenmodell

Vier Ressourcen bilden den Kern eines einfachen Gateway API Deployments.

GatewayClass definiert den Controller. Ein Cluster hat typischerweise eine:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: envoy-gateway
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller
```text

**Gateway** stellt die Listener-Infrastruktur bereit:

```yaml
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: prod-gateway
  namespace: infrastructure
spec:
  gatewayClassName: envoy-gateway
  listeners:
    - name: https
      port: 443
      protocol: HTTPS
      hostname: app.example.com
      tls:
        mode: Terminate
        certificateRefs:
          - name: app-tls
      allowedRoutes:
        namespaces:
          from: Selector
          selector:
            matchLabels:
              gateway-access: "true"
```text

**HTTPRoute** definiert die Routing-Regeln und wird vom Anwendungsteam verwaltet:

```yaml
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-route
  namespace: backend
  labels:
    gateway-access: "true"
spec:
  parentRefs:
    - name: prod-gateway
      namespace: infrastructure
      sectionName: https
  hostnames:
    - app.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: api-service
          port: 8080
          weight: 90
        - name: api-service-canary
          port: 8080
          weight: 10
      filters:
        - type: RequestHeaderModifier
          requestHeaderModifier:
            add:
              - name: X-Forwarded-Proto
                value: https
```text

**ReferenceGrant** steuert Referenzen über Namespaces hinweg. Ohne diese kann eine Route in einem Namespace nicht an ein Gateway in einem anderen Namespace angehängt werden:

```yaml
apiVersion: gateway.networking.k8s.io/v1
kind: ReferenceGrant
metadata:
  name: allow-routes-from-backend
  namespace: infrastructure
spec:
  from:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      namespace: backend
  to:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: prod-gateway
```text
Vergleichen Sie dies mit der entsprechenden Ingress-Ressource und ihren Annotationen. Die Gateway API-Version drückt dieselbe Routing-Logik, Canary-Gewichtung und Header-Manipulation deklarativ aus, ohne eine einzige Annotation.

## ingress2gateway 1.0

Veröffentlicht am 20. März 2026, nur vier Tage bevor das ingress-nginx-Repository archiviert wurde, ist [ingress2gateway 1.0](https://kubernetes.io/blog/2026/03/20/ingress2gateway-1-0-release/) das Migrations-Tool, das SIG Network entwickelt hat, um den Übergang zu erleichtern. Frühere Versionen unterstützten nur drei ingress-nginx-Annotationen. Version 1.0 verarbeitet über 30, darunter CORS, Backend-TLS, Regex-Path-Matching, Path-Rewriting, Header-Manipulation, Canary-Deployments, Timeouts und IP-Zugriffskontrolle.

Installation mit Go:

```text
go install github.com/kubernetes-sigs/ingress2gateway@v1.0.0
```text

Oder via Homebrew:

```text
brew install ingress2gateway
```text

Das Tool liest Ingress-Ressourcen aus einem Live-Cluster oder aus YAML-Dateien und gibt entsprechende Gateway API-Ressourcen aus. Wenn es auf Annotationen stößt, die es nicht übersetzen kann, werden diese nicht stillschweigend verworfen. Stattdessen werden Benachrichtigungen generiert, die jede nicht übersetzbare Konfiguration mit einer für Menschen lesbaren Erklärung und einem Vorschlag zur manuellen Behebung identifizieren. Dies ist beabsichtigt: Eine Migration ist eine Gelegenheit zum Audit, keine blinde Konvertierung.

Eine pluggable Emitter-Architektur zielt auf spezifische Gateway API-Implementierungen ab. Zu den unterstützten Emittern gehören Envoy Gateway, KGateway, AgentGateway sowie der standardmäßige Vanilla-Gateway-API-Output.

## Migrationsstrategie

Der empfohlene Ansatz ist ein Zero-Downtime-Parallelbetrieb. Sowohl Ingress- als auch Gateway API-Ressourcen können während des Übergangs auf demselben Cluster koexistieren, sofern sie an unterschiedliche Controller gebunden sind.

**Schritt 1: Gateway API CRDs installieren.** Wenden Sie die Standard-Channel-CRDs von Gateway API v1.5.0 an. Dies ist das neueste GA-Release und enthält TLSRoute v1 sowie ListenerSet v1:

```text
kubectl kustomize https://github.com/kubernetes-sigs/gateway-api/config/crd?ref=v1.5.0 | kubectl apply --server-side
```text

**Schritt 2: ingress2gateway ausführen.** Generieren Sie Gateway API-Ressourcen aus Ihren bestehenden Ingress-Manifesten:

```text
ingress2gateway print --providers=ingress-nginx --namespace=production > gateway-resources.yaml
```text

Überprüfen Sie die Ausgabe und achten Sie besonders auf den Abschnitt mit den Benachrichtigungen. Beheben Sie nicht übersetzbare Annotationen manuell.

**Schritt 3: Gateway API-Controller parallel zu Ingress bereitstellen.** Installieren Sie den gewählten Controller, zum Beispiel Envoy Gateway, ohne ingress-nginx zu entfernen. Beide Controller arbeiten unabhängig voneinander und überwachen jeweils ihre eigenen Ressourcentypen.

**Schritt 4: Testen.** Wenden Sie die generierten Gateway API-Ressourcen an. Validieren Sie das Routing, indem Sie Test-Traffic an die IP-Adresse des neuen Gateways senden oder DNS-weighted Shifting nutzen, um einen Prozentsatz des Traffics an den neuen Listener zu leiten.

**Schritt 5: Traffic umschalten.** Sobald die Validierung erfolgreich war, aktualisieren Sie Ihre DNS-Einträge oder Load-Balancer-Gewichtungen, um den gesamten Traffic über den Gateway API-Controller zu leiten.

**Schritt 6: Ingress-Ressourcen entfernen.** Löschen Sie die alten Ingress-Objekte und deinstallieren Sie den ingress-nginx-Controller. Entfernen Sie alle ingress-class-Annotationen aus den Service-Ressourcen.

## Compliance-Risiko

Der Betrieb von End-of-Life-Software im L7-Datenpfad stellt ein Compliance-Risiko dar. SOC 2 Type II, PCI-DSS und ISO 27001 verlangen alle, dass Organisationen unterstützte Software einsetzen und bekannte Schwachstellen innerhalb definierter Zeitrahmen beheben. Nach dem 24. März 2026 wird jede in ingress-nginx entdeckte CVE auf unbestimmte Zeit ungepatcht bleiben. Die vier am 2. Februar 2026 veröffentlichten CVEs mit einer Bewertung von bis zu CVSS 8.8 zeigen, dass dies kein theoretisches Risiko ist. Sicherheitsauditoren markieren ingress-nginx-Deployments in Assessments, die nach dem Retirement-Datum durchgeführt werden, bereits als Befunde.

## Was gibt es noch in 1.36

Kubernetes 1.36, das am 22. April 2026 erscheint, umfasst über 80 Verbesserungen. Die wichtigsten Änderungen im Bereich Networking und Infrastruktur:

- TLSRoute wird in Gateway API v1.5.0 GA, was SNI-basiertes Routing für TLS-Passthrough- und Termination-Use-Cases ermöglicht.
- ListenerSet wird im selben Release GA, wodurch das Limit von 16 Listenern pro Gateway-Ressource aufgehoben wird und das Self-Service-TLS-Zertifikatsmanagement für Applikations-Teams in Multi-Tenant-Clustern wiederhergestellt wird.
- User Namespaces für Pods erreicht GA und bildet den Container-Root auf nicht privilegierte Host-UIDs ab, um die Isolation zu verstärken. Dies erfordert den Linux-Kernel 5.15 oder neuer.
- HPA scale-to-zero ist nun standardmäßig aktiviert. Die Einstellung von `minReplicas: 0` ermöglicht es, dass inaktive Workloads vollständig heruntergefahren werden, was die Rechenkosten in Nicht-Produktionsumgebungen senkt.
- Das gitRepo-Volume-Plugin wird dauerhaft entfernt. Jeder Pod, der darauf verweist, wird nach dem Upgrade nicht mehr geplant (fail to schedule).
- Dynamic Resource Allocation wird Beta, wodurch natives GPU- und FPGA-Scheduling standardmäßig aktiviert wird.
- MutatingAdmissionPolicy erreicht GA und ermöglicht CEL-basierte Mutationslogik ohne Webhook-Server.
- OCI VolumeSource erreicht GA, sodass OCI-Registry-Artefakte direkt als Pod-Volumes gemountet werden können.

Achtzehn Verbesserungen werden stabil, zwanzig neue Features treten in die Alpha-Phase ein, und dieses Release markiert eines der bedeutendsten Cluster-Updates in der jüngeren Kubernetes-Geschichte.

Auditieren Sie jetzt Ihre Ingress-Ressourcen. Die Tools stehen bereit.