Von Ingress NGINX zu Gateway API migrieren vor dem End-of-Life

Dieses Tutorial ist fuer Teams, die den Community ingress-nginx Controller verwenden und einen praktischen Migrationspfad brauchen, bevor sie mit nicht unterstuetzter Edge-Infrastruktur festsitzen. Der dringende Teil ist nicht die Kubernetes Ingress API selbst. Der dringende Teil ist, dass viele Cluster auf controller-spezifisches ingress-nginx-Verhalten angewiesen sind, und diese Verhaltensweisen uebersetzen sich nicht sauber, nur indem man ein Manifest aendert.

Was diese Migration knifflig macht, ist, dass Ingress und Gateway API das Problem unterschiedlich modellieren. Bei Ingress wird viel fortgeschrittenes Verhalten in Annotations auf einem Objekt gepackt. Bei Gateway API sind Einstiegspunkte, TLS und Routing ueber mehrere Ressourcen und oft ueber verschiedene Personas verteilt. Das ist langfristig ein besseres Modell, aber es bedeutet, dass die Migration teils Uebersetzung, teils Bereinigung und teils Verhaltens-Redesign ist.

Am Ende dieses Tutorials haben Sie einen wiederholbaren Migrations-Workflow: auditieren, was ingress-nginx heute wirklich tut, Gateway API sicher installieren, ein Ingress Ende-zu-Ende uebersetzen, beide Pfade parallel betreiben, fortgeschrittene Faelle bewusst migrieren und Traffic mit Rollback-Bereitschaft umschalten. Fuer breiteren Kontext zum Retirement-Zeitplan und was er fuer Ihre Cluster bedeutet, siehe Ingress NGINX Retirement: What It Means and How to Migrate.

Schritt 1: Aktuelle Ingress-Nutzung auditieren

Beginnen Sie nicht mit YAML-Konvertierung. Beginnen Sie damit herauszufinden, was Ihr Cluster tatsaechlich verwendet. Die gefaehrlichsten Migrationen sind die, bei denen Teams annehmen, sie verwenden nur Host/Pfad-Routing und TLS, und dann spaet entdecken, dass Auth, Rewrites oder Controller-spezifische Defaults kritisch waren. Gateway APIs eigener Migrationsleitfaden warnt, dass implementierungsspezifische Ingress-Features der Teil sind, der die meiste manuelle Arbeit erfordert, und Kubernetes’ ingress-nginx-Migrationsleitfaden weist speziell auf versteckte Defaults und Seiteneffekte hin, die Ausfaelle verursachen koennen, wenn Sie zu woertlich uebersetzen.

Aktuellen Ingress-Zustand exportieren

Fuehren Sie zuerst einen Cluster-weiten Export durch.

kubectl get ingress -A -o yaml > ingress-all.yaml
kubectl get ingressclass -A -o yaml > ingressclass-all.yaml
kubectl get secret -A -o yaml > secrets-all.yaml
kubectl get configmap -A -o yaml | grep -A 40 -B 10 ingress-nginx
kubectl get pods -A -l app.kubernetes.io/name=ingress-nginx -o wide

Der letzte Befehl ist nuetzlich, weil Kubernetes ihn explizit als schnelle Methode empfiehlt, um festzustellen, ob Sie auf ingress-nginx angewiesen sind.

Hosts, Pfade und TLS inventarisieren

Erstellen Sie eine Migrationsinventardatei, die Verhalten erfasst, nicht nur Objekte.

File: ingress-migration-inventory.csv

namespace,ingress_name,host,path,path_type,tls_secret,service,service_port,ingress_class,notes
payments,payments-web,payments.example.com,/,Prefix,payments-tls,payments-web,8080,nginx,standard http app
identity,oauth-gateway,login.example.com,/oauth,Prefix,identity-tls,oauth-proxy,4180,nginx,auth headers and redirects
api,customer-api,api.example.com,/v1,Prefix,api-tls,customer-api,9000,nginx,rewrite and rate limiting
marketing,landing,www.example.com,/,Prefix,public-tls,landing,80,nginx,static content and redirect rules

Annotations und controller-spezifisches Verhalten inventarisieren

Extrahieren Sie nun Annotations, denn dort lebt der meiste Migrationsschmerz.

kubectl get ingress -A -o jsonpath='{range .items[*]}{.metadata.namespace},{.metadata.name},{.metadata.annotations}{"\n"}{end}' > ingress-annotations.txt

Suchen Sie speziell nach Mustern wie diesen:

• nginx.ingress.kubernetes.io/rewrite-target
• nginx.ingress.kubernetes.io/use-regex
• nginx.ingress.kubernetes.io/auth-url
• nginx.ingress.kubernetes.io/auth-signin
• nginx.ingress.kubernetes.io/configuration-snippet
• nginx.ingress.kubernetes.io/server-snippet
• nginx.ingress.kubernetes.io/limit-rps
• nginx.ingress.kubernetes.io/canary
• nginx.ingress.kubernetes.io/upstream-vhost

Diese sind nicht alle aequivalent in Gateway API. Einige bilden sauber auf HTTPRoute-Features ab. Andere erfordern implementierungsspezifische Policies oder ein Redesign.

Benutzerdefiniertes Verhalten finden, das an ingress-nginx gebunden ist

Der offizielle Gateway-API-Migrationsleitfaden merkt an, dass Ingress-Annotations implementierungsspezifisch sind und die Konvertierung sowohl von Ihrem aktuellen Controller als auch von Ihrer gewaehlten Gateway-Implementierung abhaengt. Kubernetes’ ingress-nginx-Migrationsleitfaden hebt auch ueberraschende Verhaltensweisen hervor, wie Regex-Semantiken, die sich von dem unterscheiden koennen, was viele Teams annehmen.

Erstellen Sie ein Arbeitsblatt fuer jedes riskante Ingress.

File: risky-ingress-checklist.md

# Risky Ingress Review

## Identity / oauth-gateway
- Uses external auth
- Adds auth request headers
- Redirects unauthenticated users
- Depends on custom nginx snippets
- Needs exact redirect and header behavior

## API / customer-api
- Uses rewrite-target
- Uses rate limits
- Uses regex path matching
- Exposes public API clients that may rely on path quirks

Sie sollten nun eine Liste aller Ingress-Objekte, ihrer Hosts und Pfade, ihrer TLS-Bindungen und der Annotations oder Verhaltensweisen haben, die am wahrscheinlichsten waehrend der Migration brechen.

Schritt 2: Ein Migrationsziel festlegen

Nehmen Sie nicht an, Gateway API sei eine Sache. Gateway API ist eine Kubernetes-API plus eine Implementierung. Ihr echtes Migrationsziel ist eine Gateway-API-Implementierung oder ein anderer unterstuetzter Controller, und das Verhalten variiert zwischen Implementierungen.

Warum Gateway API normalerweise das Standard-Ziel ist

Gateway API existiert, um mehrere Ingress-Einschraenkungen zu loesen: begrenzte Features, Ueberabhaengigkeit von Annotations und ein unzureichendes Berechtigungsmodell fuer geteilte Infrastruktur. Es bietet auch Standard-Unterstuetzung fuer haeufige Features wie Header-Matching, Request/Response-Manipulation, Traffic-Splitting und ausdruecksvolleres Routing.

Das macht es zum besten Ziel fuer die meisten Kubernetes-Teams, weil es Ihnen gibt:

• explizite Einstiegspunkte mit Gateway
• Routing-Logik in HTTPRoute
• sauberere Ownership-Grenzen zwischen Plattform- und App-Teams
• weniger Annotation-Wildwuchs
• bessere Portabilitaet ueber Controller, zumindest fuer Core-Features

Basierend auf konkreten Anforderungen waehlen

Erstellen Sie eine kurze Entscheidungsmatrix.

File: gateway-target-matrix.yaml

requirements:
  standard_http_routing: required
  tls_termination: required
  weighted_routing: required
  request_header_modification: required
  auth_policy: required
  rate_limiting: required
  regex_path_matching: required
  cross_namespace_backend_refs: maybe

candidates:
  gateway_api_envoy:
    core_conformance: yes
    extended_features_needed: yes
    policy_extensions_for_auth: yes
    rate_limit_extension: yes
  gateway_api_istio:
    core_conformance: yes
    extended_features_needed: yes
    policy_extensions_for_auth: yes
    rate_limit_extension: yes
  existing_vendor_ingress:
    direct_feature_match: maybe
    long_term_portability: lower
    migration_effort: maybe_lower_short_term

Konforme Implementierungen bevorzugen

Das Gateway-API-Projekt pflegt eine Liste konformer und teilweise konformer Implementierungen, und Konformitaet existiert, weil Portabilitaet nur funktioniert, wenn Implementierungen tatsaechlich dieselben Tests bestehen. Verwenden Sie diese Liste statt Anbieterbehauptungen.

Sie sollten nun wissen, ob Ihr Ziel eine Gateway-API-Implementierung ist, welche es ist und welche fortgeschrittenen Verhaltensweisen implementierungsspezifische Policies oder Redesign erfordern.

Schritt 3: Gateway-API-Komponenten installieren

Gateway API ist ein Add-on, nicht etwas, das jeder Cluster standardmaessig hat. Die offiziellen Docs beschreiben es als eine Add-on-Familie von API-Arten, und die Getting-Started-Guidance sagt, dass Sie entweder einen Gateway-Controller installieren koennen, der die CRDs fuer Sie installiert, oder die CRDs manuell installieren.

Die Gateway-API-CRDs installieren

Verwenden Sie den Standard-Channel, es sei denn, Sie haben einen bestimmten Grund, auf experimentelle Ressourcen angewiesen zu sein. Pruefen Sie die Gateway API Releases-Seite fuer die neueste stabile Version.

# Replace v1.4.0 with the latest stable release
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.4.0/standard-install.yaml

Dann verifizieren Sie:

kubectl get crd | grep gateway.networking.k8s.io

Ihren gewaehlten Controller installieren

Folgen Sie dem Install-Guide Ihrer Implementierung. Dieses Tutorial bleibt absichtlich anbieterneutral, weil der Controller das tatsaechliche Data-Plane-Verhalten bestimmt.

Nach der Installation verifizieren Sie die GatewayClass-Objekte, die der Controller registriert hat:

kubectl get gatewayclass

Namespaces und Berechtigungen planen

Ein Schluesselunterschied zu Ingress ist, dass Einstiegspunkte und Routen getrennt sind. Gateway APIs Migrationsleitfaden beschreibt explizite Personas: Cluster-Operatoren oder App-Admins definieren die Einstiegspunkte und TLS-Terminierung auf Gateway, waehrend Anwendungsentwickler das Routing auf HTTPRoute definieren.

Erstellen Sie von vornherein einen Namespace-Plan:

File: gateway-namespace-plan.yaml

platform_namespace: edge-system
app_namespaces:
  - payments
  - identity
  - api
  - marketing

ownership:
  gatewayclass: platform-team
  gateway: platform-team
  httproute: application-teams
  tls-secrets: platform-team

Ein Basis-Gateway erstellen

File: gateway.yaml

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: public-gateway
  namespace: edge-system
spec:
  gatewayClassName: envoy
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: All
    - name: https
      protocol: HTTPS
      port: 443
      hostname: "*.example.com"
      tls:
        mode: Terminate
        certificateRefs:
          - kind: Secret
            name: wildcard-example-com
      allowedRoutes:
        namespaces:
          from: All

Wenden Sie es an:

kubectl apply -f gateway.yaml
kubectl get gateway -n edge-system

Verifizieren, dass das Gateway programmiert ist

kubectl get gateway public-gateway -n edge-system -o yaml

Suchen Sie nach Ready- oder Programmed-Status und zugewiesenen Adressen.

Sie sollten nun Gateway-API-CRDs installiert, einen Controller laufen und ein Basis-Gateway bereit haben, an das Routen angeschlossen werden koennen.

Schritt 4: Ein Ingress in Gateway-Ressourcen uebersetzen

Migrieren Sie nun ein repraesentatives Ingress. Halten Sie die erste Uebersetzung langweilig: Standard-Host/Pfad-Routing mit TLS-Terminierung und einem Backend.

Von einem echten Ingress starten

File: ingress.yaml

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

Die passende HTTPRoute erstellen

File: payments-httproute.yaml

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: payments-web
  namespace: payments
spec:
  parentRefs:
    - name: public-gateway
      namespace: edge-system
      sectionName: https
  hostnames:
    - "payments.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: payments-web
          port: 8080

Wenden Sie es an:

kubectl apply -f payments-httproute.yaml
kubectl get httproute -n payments

HTTP-zu-HTTPS-Redirect explizit hinzufuegen

File: payments-http-redirect.yaml

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: payments-http-redirect
  namespace: payments
spec:
  parentRefs:
    - name: public-gateway
      namespace: edge-system
      sectionName: http
  hostnames:
    - "payments.example.com"
  rules:
    - filters:
        - type: RequestRedirect
          requestRedirect:
            scheme: https
            statusCode: 301

Die uebersetzte Route verifizieren

kubectl describe httproute payments-web -n payments
kubectl describe httproute payments-http-redirect -n payments

Senden Sie dann Testanfragen an die Gateway-Adresse:

export GATEWAY_IP=$(kubectl get gateway public-gateway -n edge-system -o jsonpath='{.status.addresses[0].value}')
curl -I -H "Host: payments.example.com" http://$GATEWAY_IP/
curl -k -I -H "Host: payments.example.com" https://$GATEWAY_IP/

Sie sollten nun funktionierendes Routing durch HTTPRoute sehen, mit expliziter HTTPS-Umleitung und dem Backend-Service, der Traffic empfaengt.

Schritt 5: Beide parallel betreiben

Loeschen Sie ingress-nginx nicht nach der ersten Konvertierung. Gateway APIs Migrationsleitfaden erklaert das API-Mapping, sagt aber explizit, dass er Sie nicht auf eine Live-Migration vorbereitet. Kubernetes’ ingress-nginx-Migrationsblog geht noch weiter: scheinbar korrekte Uebersetzungen koennen trotzdem wegen ingress-nginx-Eigenheiten fehlschlagen.

Separate Einstiegspunkte waehrend der Validierung verwenden

Das einfachste Side-by-Side-Modell sind separate Load-Balancer-Adressen.

• ingress-nginx bedient weiterhin Produktionstraffic
• Gateway API bekommt einen neuen Load Balancer oder eine neue Adresse
• Testtraffic geht an die neue Adresse mit demselben Host-Header

export OLD_IP=$(kubectl get svc -n ingress-nginx ingress-nginx-controller -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
export NEW_IP=$(kubectl get gateway public-gateway -n edge-system -o jsonpath='{.status.addresses[0].value}')

curl -sS -H "Host: payments.example.com" http://$OLD_IP/health
curl -sS -H "Host: payments.example.com" http://$NEW_IP/health

Verhalten vergleichen, nicht nur 200-Antworten

Erstellen Sie eine Vergleichscheckliste:

File: validation-checklist.md

# Validation Checklist

## Functional
- Host routing matches expected service
- Path routing matches expected service
- HTTP redirects to HTTPS
- TLS certificate is correct
- Response headers match expectations
- Auth flow still works
- Backend sees expected forwarded headers

## Operational
- Logs appear in the expected controller
- Metrics scrape works
- Access logs preserve useful fields
- WAF or rate limits still behave as expected

Auf versteckte Annotation-Abhaengigkeiten achten

Dies ist der Teil, den viele Teams unterschaetzen. Die Gateway-Migrations-Docs sagen, dass annotationslastige Ingress-Setups am wenigsten portabel sind.

Wenn ein Ingress verwendete:

• Regex-Pfade
• rewrite-target
• Auth-Annotations
• benutzerdefinierte Snippets
• Canary-Annotations

behandeln Sie die uebersetzte Route als verdaechtig, bis sie als aequivalent bewiesen ist.

Sie sollten nun ingress-nginx und Gateway API parallel laufen haben, mit Testtraffic, der beweist, ob das uebersetzte Verhalten wirklich aequivalent ist.

Schritt 6: Fortgeschrittene Faelle migrieren

Fortgeschrittene Migrationen sind dort, wo Gateway API maechtig wird, aber auch wo Implementierungsunterschiede am meisten ausmachen.

Rewrites

Wenn Sie nginx.ingress.kubernetes.io/rewrite-target verwendet haben, uebersetzen Sie es mit URLRewrite, wenn Ihre Implementierung es unterstuetzt.

File: api-rewrite-route.yaml

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: customer-api
  namespace: api
spec:
  parentRefs:
    - name: public-gateway
      namespace: edge-system
      sectionName: https
  hostnames:
    - "api.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v1
      filters:
        - type: URLRewrite
          urlRewrite:
            path:
              type: ReplacePrefixMatch
              replacePrefixMatch: /
      backendRefs:
        - name: customer-api
          port: 9000

Header-Manipulation

Gateway API standardisiert Request- und Response-Header-Modifikation ueber Filter.

File: header-route.yaml

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: oauth-gateway
  namespace: identity
spec:
  parentRefs:
    - name: public-gateway
      namespace: edge-system
      sectionName: https
  hostnames:
    - "login.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /oauth
      filters:
        - type: RequestHeaderModifier
          requestHeaderModifier:
            add:
              - name: X-Forwarded-Proto
                value: https
              - name: X-Auth-Source
                value: gateway
      backendRefs:
        - name: oauth-proxy
          port: 4180

Canary oder gewichtetes Routing

Gateway API unterstuetzt gewichtetes Routing ueber mehrere Backend-Refs.

File: canary-route.yaml

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: payments-canary
  namespace: payments
spec:
  parentRefs:
    - name: public-gateway
      namespace: edge-system
      sectionName: https
  hostnames:
    - "payments.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: payments-web
          port: 8080
          weight: 90
        - name: payments-web-canary
          port: 8080
          weight: 10

Auth und Rate Limiting

Hier sollten Sie implementierungsspezifische Policy-Ressourcen oder Begleitprojekte erwarten. Gateway APIs Policy-Attachment-Modell existiert fuer diese Art von Erweiterung.

Nehmen Sie nicht an, dass Ihre alten Ingress-Annotations Einzeiler-Aequivalente haben. Fuer Auth und Rate Limiting dokumentieren Sie den neuen Mechanismus explizit.

File: edge-policy-notes.md

# Edge Policy Notes

## Auth
- Previous model: ingress-nginx auth-url and auth-signin annotations
- New model: implementation-specific AuthPolicy attached to Gateway or HTTPRoute
- Validation required: redirects, headers, cookie behavior, unauthenticated responses

## Rate limiting
- Previous model: ingress-nginx limit-rps annotations
- New model: implementation-specific RateLimitPolicy
- Validation required: burst behavior, headers, status code, client IP handling

Sie sollten nun Muster fuer Rewrites, Header-Manipulation, gewichtetes Routing und einen Plan fuer Auth und Rate Limiting haben, ohne so zu tun, als waeren sie vollstaendig portabel.

Schritt 7: Sicher umschalten

In diesem Stadium sollten Sie bewiesen haben, dass der neue Pfad korrekt funktioniert. Die Umschaltung ist nun eine operationelle Aenderung, keine YAML-Uebung.

Einen Traffic-Shift-Plan waehlen

Haeufige sichere Optionen sind:

• DNS-Umschaltung auf den neuen Load Balancer
• gewichtetes DNS, wenn Ihre DNS-Plattform es unterstuetzt
• Upstream-Traffic-Manager-Shift
• Header-basierte oder Canary-Exposition fuer interne Tester zuerst

Dokumentieren Sie den Plan:

File: cutover-plan.yaml

service: payments.example.com
current_entrypoint: ingress-nginx
target_entrypoint: gateway-api
cutover_method: dns
stages:
  - stage: internal-validation
    percent: 0
  - stage: pilot-traffic
    percent: 10
  - stage: partial-cutover
    percent: 50
  - stage: full-cutover
    percent: 100

rollback:
  trigger_window_minutes: 30
  action: restore_old_dns_target

Die richtigen Signale ueberwachen

Erstellen Sie eine Umschaltungs-Checkliste.

File: cutover-monitoring.md

# Cutover Monitoring

## Gateway metrics
- 4xx rate
- 5xx rate
- latency p50/p95/p99
- listener and route status

## App metrics
- upstream 4xx/5xx
- auth failures
- login or checkout success rates
- backend saturation

## UX checks
- login redirects
- session persistence
- API client compatibility
- certificate and SNI behavior

Rollback-Trigger setzen, bevor Sie beginnen

Ein Rollback-Plan sollte numerisch sein, nicht emotional.

Beispiele:

• 5xx-Rate verdoppelt sich und bleibt 5 Minuten lang erhoeht
• Login-Erfolg sinkt um mehr als 3%
• Canary-Backend-Fehlerrate ueberschreitet Schwellenwert
• Auth-Redirects schlagen fehl oder loopen
• TLS-Handshake-Fehler steigen unerwartet

Alte Ingress-Objekte erst nach Beobachtung loeschen

Nach vollstaendiger Umschaltung lassen Sie die alten Ingress-Objekte und den Controller-Pfad fuer ein Beobachtungsfenster unberuehrt. Loeschen Sie sie erst, nachdem Sie sicher sind, dass Traffic, Auth, TLS und Anwendungsverhalten stabil sind.

Sie sollten nun ein sicheres Umschaltungsmodell mit gestufter Traffic-Bewegung, Monitoring und expliziten Rollback-Triggern haben.

Haeufige Einrichtungsprobleme

Kein Drop-in-Ersatz

Symptom: Das Team erwartet, dass eine Manifest-Uebersetzung das Verhalten automatisch bewahrt.

Ursache: Kubernetes warnt explizit, dass es keinen direkten Drop-in-Ersatz fuer ingress-nginx gibt.

Loesung: Behandeln Sie die Migration als Verhaltens-Review. Inventarisieren Sie Annotations, waehlen Sie bewusst einen Controller und validieren Sie Verhalten parallel.

Annotation-Verhalten aendert sich

Symptom: Routen kompilieren, aber Pfad-Matching oder Rewrites verhalten sich anders.

Ursache: Ingress-Annotations waren implementierungsspezifisch, und ingress-nginx hatte Eigenheiten, die in Ihrer Gateway-Implementierung nicht existieren koennten.

Loesung: Uebersetzen Sie jede riskante Annotation bewusst. Testen Sie Regex, Rewrites, Redirects und Auth separat.

TLS-Unterschiede

Symptom: TLS terminiert, aber Zertifikatsauswahl oder HTTPS-Verhalten unterscheidet sich vom alten Pfad.

Ursache: In Gateway API wird TLS auf Gateway-Listeners konfiguriert, und Downstream/Upstream-TLS werden unabhaengig modelliert.

Loesung: Validieren Sie Listener-Hostnamen, Zertifikatreferenzen, Redirects und jedes Backend-TLS-Verhalten explizit.

Controller-spezifische Features

Symptom: Auth, Rate Limiting oder WAF-Features haben kein offensichtliches Gateway-YAML-Aequivalent.

Ursache: Viele davon sind implementierungsspezifische Erweiterungen oder Policy-Attachments statt portabler Core-Features.

Loesung: Verwenden Sie das Policy-Modell Ihrer Implementierung. Halten Sie diese Policies getrennt von den Basis-Gateway- und HTTPRoute-Ressourcen, damit die Grenze offensichtlich ist.

Zusammenfassung

Der sichere Weg, von ingress-nginx zu Gateway API zu migrieren, ist nicht “alles konvertieren und hoffen.” Es ist: aktuelles Verhalten auditieren, einen Ziel-Controller basierend auf den Features waehlen, die Sie wirklich verwenden, Gateway API als geteilte Plattforminfrastruktur installieren, ein Ingress sauber uebersetzen, beide Pfade parallel validieren, dann mit Rollback-Bereitschaft umschalten.

Wenn Sie viele Cluster migrieren, standardisieren Sie den Prozess in Wellen. Beginnen Sie mit Low-Risk-Standard-Routen, dann bewegen Sie Teams, die nur Host/Pfad/TLS brauchen, dann gehen Sie annotationslastige Services an, und lassen Sie die am staerksten angepassten Edge-Cases fuer zuletzt. Nach dem Umzug standardisieren Sie drei Dinge ueber Cluster hinweg: ein Standard-Gateway-Muster, ein Route-Ownership-Modell und ein dokumentiertes Policy-Modell fuer Auth, TLS und Rate Limiting.

Diese Migration geht nicht nur darum, einen Controller zu ersetzen. Es ist eine Chance, Annotations-Schulden zu reduzieren, Routing-Ownership klarer zu machen und Ihre Edge-Konfiguration in Richtung eines portableren Kubernetes-nativen Modells zu bewegen.