Migration von Ingress-Nginx zur Gateway-API mit KubeLB

Einführung

Die Kubernetes-Ingress-API hat der Community jahrelang gute Dienste geleistet, doch ihre Einschränkungen sind hinlänglich bekannt. Es gibt keine Unterstützung für Traffic-Splitting, headerbasiertes Routing oder TCP/UDP-Routing. Alles wird in Annotationen gepackt, die sich je nach Controller unterscheiden. Wer schon einmal versucht hat, eine Ingress-Ressource von einem Controller auf einen anderen zu portieren, weiß, wie mühsam es ist, controllerspezifische Annotationen zu übersetzen, die nie für die Portabilität konzipiert wurden.

Die Gateway-API ist der offizielle Nachfolger von Ingress. Es handelt sich um eine ausdrucksstärkere, rollenorientierte API, die Infrastrukturaspekte (Gateway) vom Anwendungs-Routing (HTTPRoute) trennt. Seit der allgemeinen Verfügbarkeit (GA) mit Version 1.0 hat sie sich zum Standard entwickelt, auf den sich das gesamte Kubernetes-Netzwerk-Ökosystem zubewegt.

Auf Bare-Metal- und selbstverwalteten Clustern ist diese Migration schwieriger als in der Cloud. Es gibt keinen verwalteten Load Balancer, der den Übergang abwickelt. Man kann nicht einfach einen Schalter in der Konsole des Cloud-Anbieters umlegen. KubeLB schließt diese Lücke als Kubernetes-nativer Load Balancer, der speziell für Bare-Metal- und Multi-Cluster-Umgebungen entwickelt wurde. Er bietet eine Gateway-API-Implementierung, die dort funktioniert, wo die meisten anderen versagen.

Dieses Tutorial führt Sie durch eine vollständige Migration von Ingress-Nginx zur Gateway-API unter Verwendung von KubeLB, einschließlich der Migration von TLS-Zertifikaten und einer sicheren Umstellungsstrategie. Am Ende verfügen Sie über eine produktionsreife Gateway-API-Konfiguration, die parallel zu Ihrem bestehenden Ingress-Nginx-Controller läuft, mit einem klaren Plan für dessen Außerbetriebnahme.

Warum migrieren?

Bevor Sie mit der Migration beginnen, erfahren Sie hier, warum dies für Ihre Infrastruktur wichtig ist.

Anmerkungen sind eine Sackgasse. Ingress-Nginx stützt sich für das erweiterte Routing stark auf Annotationen. Benötigen Sie URL-Umschreibungen? Das ist nginx.ingress.kubernetes.io/rewrite-target. Ratenbegrenzung? nginx.ingress.kubernetes.io/limit-rps. Diese Annotationen sind controllerspezifisch und nicht übertragbar. Wenn Sie den Controller wechseln oder mehrere Controller unterstützen müssen, müssen Sie ganz von vorne anfangen. Dies ist kein rein theoretisches Problem – es stellt für Teams, die mehrere Cluster verwalten, eine tägliche operative Belastung dar.

Die Gateway-API ist der offizielle Kubernetes-Standard. Mit Version 1.0 hat sie den Status „General Availability“ (GA) erreicht und stellt die Zukunftsrichtung des Ökosystems dar. Große Projekte, Cloud-Anbieter und Service-Meshes arbeiten derzeit an der Unterstützung der Gateway-API. Wer weiterhin auf Ingress setzt, hinkt dem Ökosystem hinterher und verpasst neue Funktionen, die ausschließlich als Erweiterungen der Gateway-API bereitgestellt werden.

Ein rollenorientiertes Design löst echte organisatorische Probleme. Die Gateway-API sorgt für eine klare Trennung der Zuständigkeiten. Ihr Infrastrukturteam verwaltet die Gateways – die Einstiegspunkte, die TLS-Terminierung und die Konfiguration der Listener. Die Anwendungsteams verwalten die HTTPRoutes – die Routing-Regeln für ihre Dienste. Dies entspricht ganz natürlich der Arbeitsweise der meisten Unternehmen, während Ingress alles in eine einzige Ressource zwängte, an der beide Teams arbeiten mussten.

KubeLB macht dies auf Bare-Metal-Systemen möglich. Die meisten Gateway-API-Implementierungen sind an bestimmte Cloud-Anbieter gebunden – AWS Gateway Controller, die GKE-Implementierung, Azure Application Gateway. KubeLB bietet eine Gateway-API-Implementierung, die speziell für Bare-Metal- und Multi-Cluster-Umgebungen entwickelt wurde. Wenn Sie Ihre Umgebung vor Ort oder in einem Colocation-Rechenzentrum betreiben, ist KubeLB die Lösung, mit der Sie die Gateway-API nutzen können, ohne von einem Cloud-Anbieter abhängig zu sein.

Schritt 1: Überprüfen Sie Ihre aktuellen Ingress-Ressourcen

Bevor Sie irgendetwas migrieren, müssen Sie sich einen genauen Überblick darüber verschaffen, was Sie haben. Überraschungen während der Migration entstehen durch Ingress-Ressourcen, die Sie vergessen haben, oder durch Annotationen, die Sie nicht berücksichtigt haben.

Listen Sie zunächst alle Ingress-Ressourcen in allen Namespaces auf:

# Alle Ingress-Ressourcen über alle Namespaces hinweg auflisten
kubectl get ingress -A

Exportieren Sie alles zur Dokumentation. Sie benötigen diese Sicherung sowohl als Dokumentation als auch als Rollback-Artefakt:

# Jeden Ingress zur Referenz exportieren
kubectl get ingress -A -o yaml > ingress-backup.yaml

Dokumentieren Sie für jede Ingress-Ressource Folgendes:

• Hostname und Pfade
• TLS-Konfiguration (Zertifikatsschlüssel)
• Backend-Dienste und Ports
• Etwaige Anmerkungen (Ratenbegrenzung, Umschreibungen, Authentifizierung usw.)

Erstellen Sie eine Migrations-Checkliste, mit der Sie Ihren Fortschritt verfolgen können:

Tipp: Achten Sie besonders auf die Ingress-Nginx-spezifischen Anmerkungen. Einige, wie zum Beispiel nginx.ingress.kubernetes.io/rewrite-target, verfügen über direkte Entsprechungen in der Gateway-API (den URLRewrite-Filter). Andere, wie nginx.ingress.kubernetes.io/auth-url Für die externe Authentifizierung sind unter Umständen maßgeschneiderte Lösungen oder implementierungsspezifische Erweiterungen erforderlich. Ermitteln Sie diese frühzeitig, damit sie Ihre Migration später nicht behindern.

Notieren Sie sich, wie viele einzelne TLS-Zertifikate Sie haben und wie diese verwaltet werden. Wenn sie von cert-manager bereitgestellt werden, ist die Migration unkompliziert. Wenn Sie Zertifikatsgeheimnisse manuell verwalten, müssen Sie dies separat planen.

Schritt 2: Gateway-API-CRDs installieren

Die Gateway-API ist in den meisten Kubernetes-Clustern standardmäßig nicht installiert. Sie müssen die Custom Resource Definitions (CRDs) installieren, bevor Sie Gateway-API-Ressourcen erstellen können.

Installieren Sie die Standard-CRDs:

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.1.0/standard-install.yaml

Überprüfen Sie, ob die CRDs installiert sind:

kubectl get crd | grep gateway

Es sollten mindestens drei CRDs angezeigt werden:

• gateways.gateway.networking.k8s.io
• httproutes.gateway.networking.k8s.io
• gatewayclasses.gateway.networking.k8s.io

Wenn Sie zudem TCP- oder UDP-Routing benötigen (beispielsweise für Datenbankverbindungen oder Spielserver), installieren Sie stattdessen den experimentellen Kanal, der Folgendes enthält: TCPRoute und UDPRoute CRDs. Für die meisten Migrationen von Webanwendungen von Ingress-Nginx reicht der Standardkanal aus.

Schritt 3: KubeLB installieren

Nachdem die Gateway-API-CRDs eingerichtet sind, installieren Sie KubeLB als Ihre Gateway-API-Implementierung. KubeLB fungiert als Controller, der auf Gateway- und HTTPRoute-Ressourcen achtet und die zugrunde liegende Load-Balancer-Infrastruktur konfiguriert.

Füge das Helm hinzu und installiere den Manager:

helm add kubelb https://charts.kubelb.io
helm update

helm kubelb-manager kubelb/kubelb-manager \
  --namespace kubelb-system \
  --create-namespace \
  --set gatewayAPI.enabled=true

Überprüfen Sie, ob KubeLB läuft:

kubectl get pods -n kubelb-system

Alle Kapseln sollten sich in Laufen Zustand. KubeLB registriert sich automatisch als GatewayClass:

kubectl get gatewayclass

Sie sollten eine kubelb GatewayClass mit einem Akzeptiert Status. Dies teilt Kubernetes mit, dass KubeLB bereit ist, als Gateway-API-Implementierung zu fungieren.

Warnung: Wenn Sie useLoadBalancerClass: true Stellen Sie in der Konfiguration von KubeLB sicher, dass es nur auf die von Ihnen beabsichtigten LoadBalancer-Dienste ausgerichtet ist. Eine fehlerhafte Konfiguration führt dazu, dass KubeLB ALLE LoadBalancer-Dienste im Cluster verwaltet, was zu Konflikten mit bestehenden Diensten und zu einem Mangel an IP-Adressen führen kann. Beschränken Sie den Anwendungsbereich von KubeLB ausdrücklich auf seine eigene LoadBalancerClass, um dieses Problem zu vermeiden. Dies ist der häufigste Fehler bei der Bereitstellung von KubeLB.

Schritt 4: Erstellen Sie Ihr erstes Gateway

Ein Gateway ist der Einstiegspunkt für den Datenverkehr. Man kann es sich als das deklarative Äquivalent zum Ingress-Controller selbst vorstellen – es legt fest, wo der Datenverkehr in den Cluster eintritt und wie er beendet wird.

Eine Gateway-Ressource erstellen:

apiVersion: gateway.networking.k8s.io/v1
Art: Gateway
Metadaten:
  Name: Haupt-Gateway
  Namespace: Standard
  Anmerkungen:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  gatewayClassName: kubelb
  Listeners:
    - name: http
      protokoll: HTTP
      Port: 80
      zulässigeRouten:
        Namensräume:
          von: Alle
    - name: https
      Protokoll: HTTPS
      Port: 443
      TLS:
        Modus: Beenden
        Zertifikatsreferenzen:
          - name: wildcard-tls
            Art: Secret
      allowedRoutes:
        Namensräume:
          von: Alle

Es gibt einige wichtige Unterschiede zu Ingress, auf die hier besonders hingewiesen werden sollte:

• Listener sind von den Routing-Regeln getrennt. Das Gateway definiert Ports und Protokolle. Die Routing-Regeln sind in HTTPRoute-Ressourcen hinterlegt. Diese Trennung bildet die Grundlage für das rollenorientierte Design der Gateway-API.
• Die TLS-Terminierung wird auf dem Gateway konfiguriert, nicht auf einzelnen Routen. Dies ist aus betrieblicher Sicht sinnvoll – das Infrastrukturteam verwaltet TLS, und die Anwendungsteams müssen sich darum nicht kümmern.
• allowedRoutes.namespaces.from: Alle Ermöglicht es HTTPRoutes aus beliebigen Namespaces, sich an dieses Gateway anzuhängen. In der Produktion empfiehlt es sich, dies mithilfe von Label-Selektoren auf bestimmte Namespaces zu beschränken, um eine strengere Zugriffskontrolle zu gewährleisten.

Starten Sie das Gateway und warten Sie, bis es eine IP-Adresse vom KubeLB erhält:

kubectl apply -f gateway.yaml
kubectl get gateway main-gateway

Die ADRESSE Die Spalte in der Ausgabe sollte eine IP-Adresse anzeigen, sobald KubeLB den Load Balancer bereitgestellt hat. Auf diese IP-Adresse werden Sie später Ihre DNS-Einträge verweisen.

Schritt 5: Ingress-Ressourcen in HTTPRoutes konvertieren

Dies ist der Kern der Migration. Sie müssen jede Ingress-Ressource in eine oder mehrere HTTPRoute-Ressourcen umwandeln. Hier finden Sie ein systematisches Umwandlungsmuster.

Vorher (Ingress):

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  tls:
    - hosts:
        - app.example.com
      secretName: app-tls
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 8080
          - path: /
            pathType: Prefix
            backend:
              service:
                name: frontend-service
                port:
                  number: 3000

Nach (HTTPRoute):

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-route
spec:
  parentRefs:
    - name: main-gateway
  hostnames:
    - app.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      filters:
        - type: URLRewrite
          urlRewrite:
            path:
              type: ReplacePrefixMatch
              replacePrefixMatch: /
      backendRefs:
        - name: api-service
          port: 8080
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: frontend-service
          port: 3000

Beachten Sie, dass die HTTPRoute sowohl expliziter als auch strukturierter ist. Es besteht keine Unklarheit darüber, was die Umschreibung bewirkt – es handelt sich um einen typisierten Filter, nicht um eine mit regulären Ausdrücken überladene Annotation. Die parentRefs Das Feld gibt ausdrücklich an, an welches Gateway diese Route angebunden ist, wodurch die Beziehung zwischen Infrastruktur und Routing deutlich wird.

Hier ist eine Übersichtstabelle zur Umrechnung gängiger Muster:

Wende jede konvertierte HTTPRoute an:

kubectl apply -f app-route.yaml

Überprüfen Sie, ob die Route erfolgreich hinzugefügt wurde:

kubectl get httproute app-route -o yaml

Überprüfen status.parents — dort sollte Ihr Gateway mit einem Akzeptiert Bedingung festgelegt auf Richtig.

Schritt 6: TLS-Zertifikate verwalten

Die Migration von TLS-Zertifikaten ist oft der kniffligste Teil beim Wechsel von Ingress zur Gateway-API, insbesondere wenn Sie Let’s Encrypt mit DNS01-Challenges verwenden. Je nach Ihrer Konfiguration gibt es zwei Ansätze.

Option A: Vorhandene Geheimnisse wiederverwenden

Wenn cert-manager Ihre Zertifikate bereits verwaltet, funktionieren dieselben Kubernetes-Secrets auch mit der Gateway-API. Sie müssen keine neuen Zertifikate ausstellen. Verweisen Sie im Gateway-Listener auf das vorhandene Secret:

Zuhörer:
  - name: https
    Protokoll: HTTPS
    Port: 443
    TLS:
      Modus: Beenden
      Zertifikatsreferenzen:
        - name: existing-tls-secret

Dies ist der einfachste Weg. Die Zertifikate werden weiterhin vom cert-manager über die vorhandenen Zertifikatsressourcen erneuert, und das Gateway liest lediglich denselben geheimen Schlüssel.

Option B: Verwendung der Gateway-API-Integration von cert-manager

cert-manager unterstützt die Gateway-API nativ. Wenn Sie möchten, dass cert-manager Zertifikate basierend auf Ihrer Gateway-Konfiguration verwaltet, fügen Sie dem Gateway folgende Anmerkung hinzu:

Metadaten:
  Anmerkungen:
    cert-manager.io/cluster-issuer: letsencrypt-prod

Mit dieser Anmerkung überwacht cert-manager die Listener des Gateways und stellt automatisch Zertifikate für die in Ihren HTTPRoutes definierten Hostnamen bereit. Dies ist langfristig die elegantere Lösung, da sie den Lebenszyklus der Zertifikate an das Gateway bindet und nicht an veraltete Ingress-Ressourcen.

Überlegungen zur DNS01-Challenge

Beim Wechsel von der Ingress- zur Gateway-API ändern sich Ihre DNS-Einträge, da das neue Gateway eine andere IP-Adresse vom KubeLB erhält. Wenn Sie DNS01-Challenges zur Zertifikatsvalidierung verwenden, muss „external-dns“ ordnungsgemäß synchronisiert sein, damit die DNS-Einträge für die neue IP-Adresse aktualisiert werden.

Warnung: DNS01-Anfragen schlagen während der Migration häufig fehl, wenn „external-dns“ nicht so konfiguriert ist, dass die Einträge für die neue Gateway-IP aktualisiert werden. Vergewissern Sie sich vor der Umstellung, dass „external-dns“ die richtigen A/AAAA-Einträge für die IP-Adresse des Gateways erstellt hat. Verwenden Sie dig +short app.example.com um sicherzustellen, dass die IP-Adresse mit der Adresse Ihres Gateways übereinstimmt. Eine Abweichung führt dazu, dass Zertifikate nicht verlängert werden und es zu Ausfallzeiten kommt, wenn die aktuellen Zertifikate ablaufen.

Wenn Sie stattdessen HTTP01-Challenges verwenden, muss der Challenge-Solver über das Gateway erreichbar sein. Stellen Sie sicher, dass die HTTP01-Solver-Pods von cert-manager in Ihrer HTTPRoute-Konfiguration enthalten sind oder Datenverkehr über das Gateway empfangen können.

Schritt 7: Beide parallel ausführen

Führen Sie keine „Big-Bang“-Umstellung durch. Die sicherste Migrationsstrategie besteht darin, Ingress-Nginx und die Gateway-API gleichzeitig zu betreiben, wobei das DNS steuert, welcher Pfad den Produktionsdatenverkehr erhält.

Hier ist die Strategie für den parallelen Betrieb:

1. Behalten Sie Ihre bestehenden Ingress-Ressourcen bei. Sie bedienen weiterhin den Produktionsdatenverkehr über Ingress-Nginx. Für Ihre Nutzer ändert sich vorerst nichts.

2. Stellen Sie HTTPRoutes bereit, die auf dieselben Backend-Dienste verweisen. Sowohl die Ingress- als auch die HTTPRoute-Ressourcen leiten den Datenverkehr an identische Backends weiter. Die Dienste müssen nicht geändert werden.

3. Verwenden Sie DNS, um zu steuern, welcher Pfad den Datenverkehr erhält. Verweisen Sie eine Test-Subdomain zur Überprüfung auf die Gateway-IP:

# Leiten Sie eine Test-Subdomain zur Gateway-IP weiter, um die Funktion zu überprüfen
# test-app.example.com → Gateway-IP (KubeLB)
# app.example.com → Ingress-Nginx-IP (unverändert)

4. Führen Sie gründliche Tests über den Gateway-Endpunkt durch. Überprüfen Sie alle Routen, die TLS-Terminierung, Umleitungen und alle anderen Funktionen, auf die Sie angewiesen sind. Führen Sie Ihre Integrationstests mit der Test-Subdomain durch. Überprüfen Sie die Antwort-Header, um sicherzustellen, dass der Datenverkehr über KubeLB und nicht über Ingress-Nginx läuft.

5. Sobald Sie sicher sind, stellen Sie das Produktions-DNS auf die Gateway-IP um. Dies ist der eigentliche Umstellungszeitpunkt, der vollständig über das DNS gesteuert wird – nicht über Änderungen an Kubernetes-Ressourcen.

Dieser Ansatz bietet Ihnen in jeder Phase einen einfachen Weg zurück. Sollte nach der Umstellung des DNS etwas schiefgehen, leiten Sie den Datenverkehr einfach wieder auf die Ingress-Nginx-IP um. Es sind keine Änderungen an Kubernetes erforderlich.

Schritt 8: Umstellung und Außerbetriebnahme von Ingress-Nginx

Sobald der gesamte Datenverkehr über das Gateway läuft und Sie sich vergewissert haben, dass alles ordnungsgemäß funktioniert, ist es an der Zeit, aufzuräumen.

Leiten Sie Ihre DNS-Einträge in der Produktionsumgebung auf die Gateway-IP um:

# DNS umstellen: app.example.com → Gateway-IP
# Warten Sie, bis die DNS-Änderung übernommen wurde (abhängig von der TTL, in der Regel 5 Minuten bis 24 Stunden)

Überprüfen Sie, ob Datenverkehr über das Gateway läuft:

# Überprüfe die Protokolle des KubeLB-Managers auf eingehenden Datenverkehr
kubectl logs -n kubelb-system -l app=kubelb-manager--tail=100

Nachdem Sie sich vergewissert haben, dass der Produktionsdatenverkehr ordnungsgemäß über die Gateway-API läuft, entfernen Sie die alten Ingress-Ressourcen:

# Alte Ingress-Ressourcen entfernen
kubectl delete ingress app-ingress

Warten Sie eine Testphase ab, bevor Sie den Ingress-Nginx-Controller vollständig entfernen:

# Nach der Testphase (1–2 Wochen) den Ingress-Nginx-Controller entfernen
helm ingress-nginx -n ingress-nginx
kubectl delete namespace ingress-nginx

Tipp: Behalten Sie Ingress-Nginx nach der Umstellung noch 1–2 Wochen lang als Rollback-Option installiert. Deaktivieren Sie es erst, wenn Sie sicher sind, dass alle Routen über die Gateway-API korrekt funktionieren. Die Kosten für den Betrieb eines im Leerlauf befindlichen Ingress-Nginx-Controllers sind im Vergleich zu den Kosten, die entstehen, wenn kein Rollback-Pfad vorhanden ist, vernachlässigbar.

Fehlerbehebung

Verwaltung unbeabsichtigter LoadBalancer-Dienste in KubeLB

Wenn useLoadBalancerClass Wenn KubeLB falsch konfiguriert ist, versucht es, alle LoadBalancer-Dienste im Cluster zu verwalten, was zu IP-Konflikten und möglichen Dienstunterbrechungen führt.

Behebung: Legen Sie die `LoadBalancerClass` für Dienste, die von KubeLB verwaltet werden sollen, explizit fest:

Spezifikation:
  loadBalancerClass: kubelb.io/kubelb

Dadurch wird sichergestellt, dass KubeLB nur Dienste berücksichtigt, die sich ausdrücklich dafür angemeldet haben. Überprüfen Sie alle vorhandenen LoadBalancer-Dienste im Cluster, bevor Sie diese Funktion aktivieren.

Envoy : Verbindungsabbrüche bei Keep-Alive

Symptome: Die Routen werden nach Konfigurationsänderungen nicht mehr aktualisiert. Envoy zeigen Die Verbindung wurde vom Gegenüber während des Verbindungsaufbaus geschlossen.

Behebung: Überprüfen Sie die Protokolle des KubeLB-Manager-Pods auf xDS-Verbindungsfehler. Starten Sie den Manager-Pod neu, wenn die xDS-Verbindung unterbrochen ist:

kubectl rollout restart deployment kubelb-manager -n kubelb-system

Bei anhaltenden Problemen erhöhen Sie das xDS-Keep-Alive-Intervall in der Helm -Konfiguration von KubeLB. Dies tritt häufiger in Umgebungen mit strengen Netzwerk-Timeouts oder Firewalls zwischen den Knoten auf.

Fehler bei der DNS01-Zertifikatsüberprüfung

Symptome: Zertifikate, die feststecken In Bearbeitung Die Protokolle von cert-manager zeigen, dass die Authentifizierung für DNS01 fehlgeschlagen ist.

Behebung: Überprüfen Sie, ob „external-dns“ TXT-Einträge für die ACME-Challenge erstellt:

dig _acme-challenge.app.example.com TXT

Überprüfen Sie die Protokolle von „external-dns“ auf Fehler. Häufige Ursachen sind falsche Anmeldedaten des Cloud-Anbieters, Probleme bei der DNS-Zonen-Delegierung oder die Tatsache, dass der „external-dns“-Controller die Gateway-Ressourcen nicht überwacht (er muss mit dem --source=gateway-httproute (Flag).

HTTPRoute wird nicht mit dem Gateway verbunden

Symptome: HTTPRoute zeigt status.parents entweder leer oder mit einem Fehlerzustand.

Lösung: Überprüfen Sie, ob die HTTPRoute parentRefs stimmt genau mit dem Gateway-Namen und dem Namensraum überein. Überprüfen Sie den Gateway- zulässige Routen erlaubt Routen aus dem Namensraum der HTTPRoute. Ein häufiger Fehler ist es, die HTTPRoute in einem Namensraum zu erstellen, den das Gateway nicht zulässt:

kubectl get httproute app-route -o jsonpath='{.status.parents}' | jq .

Wenn die Bedingungen anzeigen Nicht erlaubt, aktualisieren Sie die zulässige Routen den Namensraum der HTTPRoute einzubeziehen oder die HTTPRoute in einen zulässigen Namensraum zu verschieben.

Referenz zur Migration von Common Annotation

Diese Tabelle enthält die am häufigsten verwendeten Ingress-Nginx-Annotationen und ihre Entsprechungen in der Gateway-API:

Warnung: Nicht alle Ingress-Nginx-Annotationen haben direkte Entsprechungen in der Gateway-API. Funktionen wie die externe Authentifizierung (auth-url) und erweiterte Ratenbegrenzung erfordern unter Umständen implementierungsspezifische Erweiterungen oder benutzerdefinierte Filter. Überprüfen Sie diese in Schritt 1 und planen Sie alternative Implementierungen, bevor Sie mit der Migration beginnen. Es darf während der Umstellung nicht zu dem Feststellen fehlender Funktionen kommen.

Nächste Schritte

• Was ist KubeLB? (in Kürze verfügbar) – Erfahren Sie mehr über die Architektur von KubeLB und wie es den Lastausgleich zwischen Clustern verwaltet
• KubeLB mit KubeOne: Kompletter Bare-Metal-Netzwerkstack (in Kürze verfügbar) – kombinieren Sie KubeLB mit KubeOne für eine umfassende Bare-Metal-Netzwerklösung
• Bare-Metal-Kubernetes mit KubeOne und Terraform – Richten Sie den Cluster ein, für den KubeLB den Lastausgleich übernimmt

Zusammenfassung

Sie haben von Ingress-Nginx auf die Gateway-API umgestellt und dabei KubeLB als Implementierung verwendet. Die wichtigsten Schritte waren: Überprüfung der vorhandenen Ingress-Ressourcen, Installation der Gateway-API-CRDs und von KubeLB, Erstellung eines Gateways mit Listenern, Konvertierung der Ingress-Ressourcen in HTTPRoutes, Migration der TLS-Zertifikate, paralleler Betrieb beider Systeme und Umstellung über DNS.

Die größten Risiken bei dieser Migration sind fehlgeschlagene DNS01-Challenges während der Zertifikatsmigration sowie eine fehlerhafte Konfiguration des „LoadBalancerClass“-Gültigkeitsbereichs bei KubeLB. Beides lässt sich durch eine sorgfältige Vorbereitung in der Audit-Phase vermeiden.

Die Strategie des parallelen Betriebs ist in Produktionsumgebungen unabdingbar. Lassen Sie beide Systeme mindestens eine Woche lang gleichzeitig laufen, bevor Sie Ingress-Nginx außer Betrieb nehmen. Die Kosten für den Betrieb eines im Leerlauf befindlichen Controllers sind verschwindend gering im Vergleich zu den Kosten einer fehlgeschlagenen Migration ohne Rollback-Möglichkeit.

Die Gateway-API bietet Ihnen eine ausdrucksstärkere, portablere und wartungsfreundlichere Netzwerkebene. KubeLB sorgt dafür, dass dies auch auf Bare-Metal-Systemen funktioniert, wo andere Implementierungen versagen. Zusammen bilden sie einen produktionsreifen Netzwerkstack, der sich an Ihre Infrastrukturanforderungen anpasst.