← Alle Beiträge

Ingress Migration Strategie: Von veralteten Controllern zur Gateway API

Matthias Bruns · · 7 Min. Lesezeit
kubernetes ingress gateway-api migration

Die Ankündigung der Kubernetes-Community über die Einstellung von Ingress NGINX im März 2026 hat einen dringenden Bedarf für Migrationsplanung in Tausenden von Produktions-Clustern geschaffen. Da keine Sicherheits-Patches, Bugfixes oder Updates nach dem finalen v1.15.1 Release kommen werden, müssen Unternehmen jetzt handeln, um zu vermeiden, dass sie nicht gewartete Software mit eskalierenden Sicherheitsrisiken betreiben.

Es geht nicht nur darum, einen Ingress-Controller gegen einen anderen auszutauschen. Es ist eine Gelegenheit, Ihren Kubernetes-Netzwerk-Stack mit besseren Abstraktionen, verbesserten Sicherheitsmodellen und zukunftssicheren Architekturen zu modernisieren. Dieser Leitfaden bietet ein praktisches Framework zur Bewertung Ihrer Optionen und Durchführung einer Zero-Downtime-Migration.

Verstehen des aktuellen Zustands

Bevor Sie einen Migrationspfad wählen, müssen Sie prüfen, was Sie tatsächlich verwenden. Das Migration Assessment Tool hilft bei der Identifikation von Feature-Abhängigkeiten, aber beginnen Sie mit dieser grundlegenden Prüfung:

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

Wenn dies Pods zurückgibt, sind Sie betroffen. Katalogisieren Sie nun Ihre Ingress-Ressourcen und deren Komplexität:

kubectl get ingress --all-namespaces -o yaml > current-ingress-config.yaml
kubectl get configmap -n ingress-nginx ingress-nginx-controller -o yaml > current-configmap.yaml

Achten Sie besonders auf:

  • Custom Annotations jenseits des einfachen Path-Routings
  • ConfigMap-Anpassungen für globales Verhalten
  • TCP/UDP-Services-Konfiguration
  • SSL/TLS-Terminierung-Patterns
  • Rate Limiting und Authentifizierungs-Regeln

Die Komplexität dieser Konfigurationen bestimmt Ihre Migrationsstrategie und Ihren Zeitplan.

Migrationspfad-Optionen

Sie haben drei primäre Migrationsziele, jedes mit unterschiedlichen Trade-offs:

F5 NGINX Ingress Controller

Der direkteste Pfad für Teams, die stark in NGINX-spezifische Features investiert haben. NGINX Ingress Controller v5.4.0 führt native Validierung und CORS-Unterstützung ein, speziell um ingress-nginx-Migrationen zu erleichtern.

Am besten für: Unternehmen mit komplexen NGINX-Konfigurationen, Custom Snippets oder NGINX Plus-Lizenzierung.

Migrationskomplexität: Niedrig bis mittel, abhängig von der Annotation-Nutzung.

Gateway API mit Envoy Gateway

Die zukunftsorientierte Wahl, die Kubernetes’ Netzwerk-Zukunft umarmt. Gateway API bietet rollenbasierte Konfiguration, bessere Traffic-Management-Primitive und Anbieter-Neutralität.

Am besten für: Teams, die neue Anwendungen entwickeln oder bereit sind, in moderne Kubernetes-Netzwerk-Patterns zu investieren.

Migrationskomplexität: Mittel bis hoch, erfordert ein Überdenken von Traffic-Management-Konzepten.

Cloud Provider Solutions (ALB, GKE Ingress, etc.)

Plattform-spezifische Controller, die sich tief in Cloud-Load-Balancer integrieren. AWS empfiehlt, zuerst zum AWS Load Balancer Controller zu migrieren, dann zur Gateway API, wenn bereit.

Am besten für: Teams, die bereits einer bestimmten Cloud-Plattform verpflichtet sind.

Migrationskomplexität: Mittel, mit Vendor Lock-in-Überlegungen.

Risikobewertungs-Framework

Bewerten Sie jede Migrationsoption anhand dieser kritischen Faktoren:

Feature-Paritäts-Analyse

Nicht jedes ingress-nginx-Feature hat direkte Äquivalente in alternativen Controllern. Erstellen Sie ein Feature-Mapping-Dokument:

# Beispiel Feature-Assessment
current_features:
  - ssl_redirect: "nginx.ingress.kubernetes.io/ssl-redirect"
  - rate_limiting: "nginx.ingress.kubernetes.io/rate-limit"
  - custom_headers: "nginx.ingress.kubernetes.io/configuration-snippet"
  
migration_gaps:
  nginx_controller:
    - ssl_redirect: "Direkte Annotation-Unterstützung"
    - rate_limiting: "VirtualServer CRD erforderlich"
    - custom_headers: "Policy CRD empfohlen"
  
  gateway_api:
    - ssl_redirect: "HTTPRoute redirect filter"
    - rate_limiting: "Implementierungsspezifische Policy"
    - custom_headers: "ExtensionRef zu Controller Policy"

Operationelle Auswirkungen

Berücksichtigen Sie den Blast Radius Ihrer Migration:

  • Traffic-Patterns: Spitzenlastzeiten, in denen Sie sich keine Unterbrechungen leisten können
  • Team-Expertise: Lernkurve für neue APIs und Troubleshooting
  • Tooling-Integration: CI/CD-Pipelines, Monitoring und GitOps-Workflows
  • Compliance-Anforderungen: Change Management und Genehmigungsprozesse

Sicherheits-Implikationen

Jeder Migrationspfad hat unterschiedliche Sicherheitscharakteristika:

  • NGINX Ingress Controller: Vertrautes Sicherheitsmodell, erfordert aber laufendes Lizenz-Management für Plus-Features
  • Gateway API: Rollenbasierte Zugriffskontrolle (RBAC) mit Trennung der Belange zwischen Plattform- und Anwendungsteams
  • Cloud-Controller: Integration mit Cloud IAM und Sicherheitsdiensten

Zero-Downtime-Migrationsmuster

Pattern 1: Parallele Controller-Migration

Betreiben Sie beide Controller gleichzeitig während der Übergangszeit. Dieser Ansatz minimiert das Risiko, erfordert aber sorgfältiges Traffic-Management.

# Neuen Controller in separatem Namespace installieren
kubectl create namespace nginx-ingress-new

# Mit unterschiedlicher Ingress Class deployen
helm install nginx-ingress-new nginx-stable/nginx-ingress \
  --namespace nginx-ingress-new \
  --set controller.ingressClass=nginx-new

Migrieren Sie Services schrittweise durch Aktualisierung des ingressClassName-Feldes:

# Vorher
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-app
spec:
  ingressClassName: nginx  # Alter Controller
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: example-service
            port:
              number: 80

# Nachher
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-app
spec:
  ingressClassName: nginx-new  # Neuer Controller
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: example-service
            port:
              number: 80

Pattern 2: Blue-Green Cluster-Migration

Für Unternehmen mit ausgereiften Deployment-Pipelines bietet die Migration ganzer Cluster die sauberste Trennung.

# Neuen Cluster mit Ziel-Ingress-Controller erstellen
# Anwendungen auf neuem Cluster deployen
# DNS/Load-Balancer-Traffic umschalten
# Alten Cluster außer Betrieb nehmen

Dieses Pattern funktioniert gut mit GitOps-Workflows, bei denen Infrastruktur und Anwendungen zusammen versioniert werden.

Pattern 3: Gateway API Progressive Migration

Bei der Migration zur Gateway API beginnen Sie mit grundlegendem HTTP-Routing und übernehmen schrittweise erweiterte Features:

# Phase 1: Grundlegendes Routing
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-app
spec:
  parentRefs:
  - name: example-gateway
  hostnames:
  - app.example.com
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: example-service
      port: 80

# Phase 2: Traffic-Policies hinzufügen
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-app
spec:
  parentRefs:
  - name: example-gateway
  hostnames:
  - app.example.com
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    filters:
    - type: RequestRedirect
      requestRedirect:
        scheme: https
        statusCode: 301
    backendRefs:
    - name: example-service
      port: 80

Migrations-Ausführungsstrategie

Phase 1: Vorbereitung (Wochen 1-2)

  1. Aktuelle Konfiguration auditieren mit dem NGINX Migration Tool
  2. Staging-Umgebung aufsetzen, die Produktions-Traffic-Patterns spiegelt
  3. Team-Mitglieder schulen in neuen APIs und Troubleshooting-Ansätzen
  4. Monitoring und Alerting aktualisieren für neue Controller-Metriken und -Logs

Phase 2: Pilot-Migration (Wochen 3-4)

  1. Risikoarme Anwendungen auswählen mit einfachen Routing-Anforderungen
  2. Ziel-Controller deployen parallel zum bestehenden Setup
  3. Pilot-Anwendungen migrieren und Funktionalität validieren
  4. Lessons Learned dokumentieren und Migrations-Verfahren verfeinern

Phase 3: Produktions-Migration (Wochen 5-8)

  1. Migrations-Zeitplan erstellen mit Priorisierung der Anwendungen nach Kritikalität
  2. Automatisierte Tests implementieren zur Validierung jedes Migrations-Schritts
  3. Migrationen während Wartungsfenstern ausführen mit Rollback-Verfahren
  4. Anwendungsperformance überwachen und User Experience-Metriken

Phase 4: Cleanup (Wochen 9-10)

  1. Alten Ingress-Controller entfernen nach Migration aller Anwendungen
  2. Dokumentation aktualisieren und Runbooks für neue Architektur
  3. Post-Migration-Review durchführen zur Erfassung von Verbesserungen für zukünftige Migrationen

Automatisierung und Tooling

Das NGINX Ingress Migration Tool bietet automatisierte Assessment- und Konvertierungs-Vorschläge. Für Gateway API-Migrationen ziehen Sie Tools wie diese in Betracht:

  • Gateway API Conformance Tests zur Validierung des Controller-Verhaltens
  • Helm Chart Templating zur Generierung sowohl von Ingress- als auch Gateway API-Ressourcen während der Übergangszeit
  • GitOps-Automatisierung zum Management von Konfigurationsdrift zwischen Umgebungen

Häufige Fallstricke und Lösungen

Annotation Hell

Viele Teams entdecken, dass sie Dutzende von Controller-spezifischen Annotations verwenden. Die NGINX-Dokumentation empfiehlt einen “CRD-first”-Ansatz, der zu policy-basierter Konfiguration statt Annotation-Wildwuchs migriert.

Load Balancer IP-Änderungen

Cloud-Controller-Migrationen führen oft zu neuen Load Balancer-IPs. Planen Sie DNS TTL-Reduzierungen und erwägen Sie CNAME-Records, die auf Load Balancer-Hostnamen zeigen, statt A-Records mit IPs.

Feature-Lücken

Nicht jedes ingress-nginx-Feature hat direkte Äquivalente. Dokumentieren Sie diese Lücken früh und planen Sie Workarounds oder Anwendungsänderungen. Manchmal stellt das “fehlende” Feature eine Gelegenheit dar, Ihre Architektur zu vereinfachen.

Blick nach vorn

Die ingress-nginx-Einstellung erzwingt eine Entscheidung, die viele Teams aufgeschoben haben. Obwohl kurzfristig störend, bietet diese Migration eine Gelegenheit, Ihren Kubernetes-Netzwerk-Stack mit besseren Sicherheitsmodellen, verbesserter Observability und zukunftssicheren APIs zu modernisieren.

Gateway API repräsentiert die Zukunft des Kubernetes-Networkings mit wachsender Ökosystem-Unterstützung und Anbieter-Adoption. Selbst wenn Sie ein Zwischen-Migrationsziel wie NGINX Ingress Controller oder eine Cloud Provider-Lösung wählen, planen Sie für eine eventuelle Gateway API-Adoption, während der Standard reift.

Der Schlüssel zum Erfolg liegt darin, früh zu beginnen, gründlich zu testen und schrittweise zu migrieren. Die Deadline im März 2026 mag entfernt erscheinen, aber komplexe Produktionsumgebungen erfordern Monate der Planung und Validierung, um Zero-Downtime-Übergänge sicherzustellen.

Ihr zukünftiges Ich wird Ihnen dafür danken, dass Sie in diese Migration ordentlich investiert haben, anstatt unter Deadline-Druck hindurchzuhetzen.

Lesebarkeit

Schriftgröße