Migration vom Ingress- NGINX zum Traefik-Ingress-Controller

Stellen Sie Ihr Ingress-Setup so um, dass statt des Ingress- NGINX-Controllers der Traefik-Controller verwendet wird.

Vorbereitende Schritte

Überprüfen Sie diese Voraussetzungen vor der Migration.

  1. Stellen Sie sicher, dass Sie über die erforderlichen Berechtigungen verfügen.

    • Plattformzugriffsrolle Administrator für den Cluster
    • Servicezugriffsrolle Manager in allen Namensbereichen

  2. Überprüfen Sie vorhandene Ingress-Ressourcen auf Ingress- NGINX-spezifische Anmerkungen oder Konfigurationen. Lesen Sie die Dokumentation zu den wichtigsten Unterschieden zwischen den beiden Ingress-Controllern durch.

  3. Planen Sie Ihre Migrationsstrategie auf der Grundlage der Anforderungen an die Arbeitslast, der Ausfalltoleranz und der Verfügbarkeit von Ressourcen. Beide Controller können während der Migration gleichzeitig laufen.

  4. Stellen Sie sicher, dass Ihr Cluster zur Gewährleistung einer hohen Verfügbarkeit über mindestens zwei Worker-Knoten pro Zone verfügt.

  5. Sichern Sie Ihre aktuellen Ingress-Konfigurationen, bevor Sie Änderungen vornehmen.

Strategie 1: Separate Ingress-Konfiguration mit einer anderen Domain

Testen Sie Traefik in einer separaten Umgebung, während die Produktionsumgebung weiterhin auf Ingress läuft – NGINX. Diese Strategie gewährleistet ein Höchstmaß an Isolation und Sicherheit.

Wenden Sie diese Strategie in folgenden Fällen an:

  • Sie sollten Traefik gründlich testen, bevor Sie Produktions-Workloads migrieren.
  • Sie können einen anderen Satz von Anwendungen für Testzwecke bereitstellen.
  • Sie verfügen über die Ressourcen, um weitere ALBs zu betreiben.
  • Sie möchten, dass während der Testphase keinerlei Risiko für Ihre Produktionsumgebung besteht.

Schritte

  1. Verfügbare Traefik-Versionen abrufen.
    ibmcloud ks ingress alb versions
  2. Erstellen Sie eine neue ALB mit Traefik.

Klassische Cluster sh {: pre} ibmcloud ks ingress alb create classic --cluster CLUSTER_NAME --type PUBLIC_OR_PRIVATE --zone ZONE --vlan VLAN_ID --version TRAEFIK_VERSION VPC-Cluster sh {: pre} ibmcloud ks ingress alb create vpc-gen2 --cluster CLUSTER_NAME --type PUBLIC_OR_PRIVATE --zone ZONE --version TRAEFIK_VERSION

  1. Stellen Sie für VPC-Cluster zu Testzwecken manuell einen zusätzlichen „ LoadBalancer “-Dienst bereit. Legen Sie „ spec.selector “ so fest, dass „ app.kubernetes.io/vpcComponent: public-cr<cluster_id>-traefik “ (oder „ private-cr<cluster_id>-traefik “ für private ALBs) enthalten ist. In Classic-Clustern wird automatisch ein neuer Load Balancer bereitgestellt, sodass keine zusätzliche Konfiguration erforderlich ist.

  2. Richten Sie eine benutzerdefinierte Domain für den Traefik-ALB ein und verweisen Sie diese auf den Hostnamen oder die IP-Adresse des Load Balancers. Ausführliche Anweisungen finden Sie unter „ Benutzerdefinierte Domains erstellen “.

  3. Erstellen Sie mithilfe der Traefik-Ingress-Klasse eine Ingress-Ressource für Testanwendungen. Befolgen Sie Schritt 3: Erstellen Sie die Ingress-Ressource und geben Sie dabei ingressClassName: public-iks-traefik an (oder private-iks-traefik für private ALBs).

  4. Testen Sie Anwendungen über die Traefik-Domäne und überprüfen Sie deren Funktionalität.

  5. Fahren Sie nach Abschluss der Tests mit dem Abschnitt „Umstellung“ fort, um Ihre Produktions-Workloads zu migrieren.

Strategie 2: Zwei Load Balancer mit identischer Arbeitslast

Testen Sie beide Controller mit derselben Arbeitslast, indem Sie zwei Ingress-Ressourcen erstellen, die auf denselben Dienst verweisen. Sie können das Verhalten der Controller direkt vergleichen, ohne den Produktionsdatenverkehr zu beeinträchtigen.

Wenden Sie diese Strategie in folgenden Fällen an:

  • Sie möchten das Verhalten von Ingress- NGINX und Traefik bei derselben Arbeitslast vergleichen.
  • Sie müssen sicherstellen, dass Traefik Ihre spezifische Anwendung korrekt verarbeitet.
  • Sie können den Test mit einer Testdomain durchführen.
  • Sie möchten die Anzahl der erforderlichen Testanwendungen so gering wie möglich halten.

Schritte

  1. Aktivieren Sie eine neue ALB mit einer auf Traefik basierenden Version.

Klassische Cluster sh {: pre} ibmcloud ks ingress alb create classic --cluster CLUSTER_NAME --type PUBLIC_OR_PRIVATE --zone ZONE --vlan VLAN_ID --version TRAEFIK_VERSION VPC-Cluster sh {: pre} ibmcloud ks ingress alb create vpc-gen2 --cluster CLUSTER_NAME --type PUBLIC_OR_PRIVATE --zone ZONE --version TRAEFIK_VERSION

  1. Stellen Sie für VPC-Cluster zu Testzwecken manuell einen zusätzlichen „ LoadBalancer “-Dienst bereit. Legen Sie „ spec.selector “ so fest, dass „ app.kubernetes.io/vpcComponent: public-cr<cluster_id>-traefik “ (oder „ private-cr<cluster_id>-traefik “ für private ALBs) enthalten ist. In Classic-Clustern wird automatisch ein neuer Load Balancer bereitgestellt, sodass keine zusätzliche Konfiguration erforderlich ist.

  2. Richten Sie eine benutzerdefinierte Domain für den Traefik-ALB ein und verweisen Sie diese auf den Hostnamen oder die IP-Adresse des Load Balancers. Ausführliche Anweisungen finden Sie unter „ Benutzerdefinierte Domains erstellen “.

  3. Erstellen Sie eine zweite Ingress-Ressource, die die Traefik-Ingress-Klasse verwendet, aber auf denselben Dienst verweist wie Ihre bestehende Ingress-Ressource „ NGINX “. Befolgen Sie die Anweisungen in Schritt 3: „Ingress-Ressource erstellen“ und achten Sie dabei darauf, dass Sie:

    • Geben Sie „ ingressClassName: public-iks-traefik “ an (oder „ private-iks-traefik “ für private ALBs)
    • Verwenden Sie denselben Wert für „ service.name “, den Ihre bestehende Ingress-Ressource unter NGINX verwendet
    • Geben Sie Ihre Testdomain in die Felder „ host “ und „ tls.hosts “ ein

  4. Testen Sie Ihre Anwendung über beide Domänen hinweg.

    • Zugriff über die Ingress-Domain NGINX (Produktionsumgebung)
    • Zugriff über die Traefik-Domäne (Test)

  5. Vergleichen Sie das Verhalten, die Leistung und die Funktionalität der beiden Controller.

  6. Fahren Sie nach der Validierung mit dem Abschnitt „Umstellung“ fort, um Ihre Produktionsdomain zu Traefik zu migrieren.

Strategie 3: Split-DNS-Tests

Verwenden Sie eine Split-DNS-Konfiguration, um Traefik mit Ihrer Produktionsdomain in einer produktionsnahen Umgebung zu testen, ohne dass Ihre Nutzer davon beeinträchtigt werden.

Wenden Sie diese Strategie in folgenden Fällen an:

  • Sie möchten mit Ihrer tatsächlichen Produktionsdomain testen.
  • Sie haben die Kontrolle über die DNS-Konfiguration Ihrer Testumgebung.
  • Sie müssen die genaue Produktionskonfiguration überprüfen.
  • Sie möchten die Unterschiede zwischen Test- und Produktionsumgebung so gering wie möglich halten.

Schritte

  1. Aktivieren Sie eine neue ALB mit einer auf Traefik basierenden Version.

Klassische Cluster sh {: pre} ibmcloud ks ingress alb create classic --cluster CLUSTER_NAME --type PUBLIC_OR_PRIVATE --zone ZONE --vlan VLAN_ID --version TRAEFIK_VERSION VPC-Cluster sh {: pre} ibmcloud ks ingress alb create vpc-gen2 --cluster CLUSTER_NAME --type PUBLIC_OR_PRIVATE --zone ZONE --version TRAEFIK_VERSION

  1. Stellen Sie für VPC-Cluster zu Testzwecken manuell einen zusätzlichen „ LoadBalancer “-Dienst bereit. Legen Sie „ spec.selector “ so fest, dass „ app.kubernetes.io/vpcComponent: public-cr<cluster_id>-traefik “ (oder „ private-cr<cluster_id>-traefik “ für private ALBs) enthalten ist. In Classic-Clustern wird automatisch ein neuer Load Balancer bereitgestellt, sodass keine zusätzliche Konfiguration erforderlich ist.

  2. Rufen Sie die IP-Adresse (klassisch) oder den Hostnamen (VPC) des neuen Traefik-ALB ab.

    ibmcloud ks ingress alb ls --cluster CLUSTER_NAME

  3. Konfigurieren Sie Split-DNS in Ihrer Testumgebung.

    • Konfigurieren Sie DNS für Ihre Testrechner oder Ihr Netzwerk so, dass Ihre Produktionsdomain auf die IP-Adresse bzw. den Hostnamen des Traefik-ALB aufgelöst wird
    • Die Produktionsbenutzer werden weiterhin über den Ingress- NGINX-ALB weitergeleitet
    • Dies kann über lokale „ /etc/hosts “-Dateien, interne DNS-Server oder VPN-spezifische DNS-Konfigurationen erfolgen

  4. Erstellen Sie mithilfe der Traefik-Ingress-Klasse eine neue Ingress-Ressource mit Ihrer Produktionsdomain. Befolgen Sie Schritt 3: Erstellen Sie die Ingress-Ressource und geben Sie dabei ingressClassName: public-iks-traefik (oder private-iks-traefik für private ALBs) sowie Ihre Produktionsdomain in den Feldern „ host “ und „ tls.hosts “ an.

  5. Führen Sie in Ihrer Split-DNS-Umgebung einen Test durch, um Traefik mit der Produktionsdomain und der Produktionskonfiguration zu überprüfen.

  6. Fahren Sie nach der Validierung mit dem Abschnitt „Umstellung vornehmen“ fort, um die Produktions-DNS so zu aktualisieren, dass sie auf Traefik verweist.

Strategie 4: Direkte Migration

Wechseln Sie direkt von Ingress- NGINX zu Traefik – mit minimalen Konfigurationsänderungen und geringem Aufwand bei der Ressourcenverwaltung.

Diese Strategie führt während der Migration zu Betriebsunterbrechungen. Planen Sie vor Beginn ein Wartungsfenster ein.

Wenden Sie diese Strategie in folgenden Fällen an:

  • Sie haben ein geringes Arbeitsaufkommen oder nutzen nicht kritische Anwendungen.
  • Sie können während der Migration kurze Ausfallzeiten in Kauf nehmen.
  • Sie möchten die Anzahl der zu verwaltenden Ressourcen so gering wie möglich halten.
  • Sie haben die Kompatibilität mit Traefik bereits in einer anderen Umgebung überprüft.
  • Bei „Classic“ müssen Sie die IP-Adressen Ihrer ALBs unverändert lassen, da Ihre Clients die Verbindung über IP-Adressen statt über DNS-Domänen herstellen.

Beim Deaktivieren und erneuten Aktivieren eines ALB bleibt dessen ursprüngliche IP-Adresse erhalten, es sei denn, diese IP-Adresse wurde in der Zwischenzeit von anderen Diensten belegt. Weitere Informationen finden Sie unter „ ALBs aktivieren oder deaktivieren “.

Schritte

  1. Rufen Sie die ID Ihres aktuellen Ingress- NGINX-ALB ab.

    ibmcloud ks ingress alb ls --cluster CLUSTER_NAME

  2. Deaktivieren Sie den Ingress- NGINX-ALB.

    ibmcloud ks ingress alb disable --alb ALB_ID --cluster CLUSTER_NAME

    VPC-Cluster: Wenn Sie Ihren letzten öffentlichen oder privaten ALB deaktivieren, warten Sie, bis die ALB-Bereitstellung und die zugehörige Load-Balancer-Service-Ressource gelöscht wurden, bevor Sie einen Traefik-ALB aktivieren.

  3. Aktivieren Sie den ALB mit einer Traefik-Version.

Klassische Cluster sh {: pre} ibmcloud ks ingress alb enable classic --alb ALB_ID --version TRAEFIK_VERSION --cluster CLUSTER_NAME Um eine bestimmte IP-Adresse für den ALB in der klassischen Umgebung zu verwenden, setzen Sie das Flag „ --ip “. Weitere Informationen finden Sie unter „ ALBs aktivieren oder deaktivieren “.

[VPC-Cluster]{: tag-vpc}
```sh {: pre}
ibmcloud ks ingress alb enable vpc-gen2 --alb ALB_ID --version TRAEFIK_VERSION --cluster CLUSTER_NAME
```
  1. Legen Sie für VPC-Cluster als Backend des Load Balancers „Traefik“ fest.

VPC-Cluster sh {: pre} ibmcloud ks ingress load-balancer backend set --cluster CLUSTER-ID --public-backend traefik [--private-backend traefik]

  1. Aktualisieren Sie Ihre Ingress-Ressourcen, damit die Traefik-Ingress-Klasse verwendet wird. Wenn in Ihren Ressourcen die Ingress-Klasse explizit festgelegt ist, ändern Sie „ spec.ingressClassName “ von „ public-iks-k8s-nginx “ in „ public-iks-traefik “ (bzw. bei privaten ALBs von „ private-iks-k8s-nginx “ in „ private-iks-traefik “).

  2. Wenden Sie die aktualisierten Ingress-Ressourcen an.

    kubectl apply -f ingress.yaml

  3. Stellen Sie sicher, dass Ihre Anwendungen über den Traefik-Controller erreichbar sind.

    curl https://<domain>/<app_path>

Umstieg auf Traefik

Stellen Sie nach Abschluss der Tests den Produktionsdatenverkehr auf den Traefik-Controller um. Die Schritte unterscheiden sich je nach klassischem Cluster und VPC-Cluster. Wählen Sie die Option aus, die Ihrem Clustertyp und Ihrer Konfiguration entspricht.

Klassische Cluster

Bei klassischen Clustern müssen Sie Ihre Produktionsdomain so anpassen, dass sie auf den Load Balancer verweist, der Traefik anstelle von Ingress bereitstellt – NGINX.

Option 1: Die Domain-Zuordnung aktualisieren

  1. Rufen Sie die IP-Adresse Ihres Traefik-ALB ab.
    ibmcloud ks ingress alb ls --cluster CLUSTER_NAME
  2. Passen Sie Ihre Domain so an, dass sie auf den Traefik-ALB verweist.
    ibmcloud ks ingress domain update --cluster CLUSTER_NAME --domain DOMAIN_NAME --ip TRAEFIK_ALB_IP
  3. Überprüfen Sie die Aktualisierung der Domain.
    ibmcloud ks ingress domain ls --cluster CLUSTER_NAME
  4. Testen Sie Ihre Anwendungen über die Produktionsdomäne, um sicherzustellen, dass sie nun von Traefik bereitgestellt werden.

Option 2: Deaktivieren der ALBs „Ingress- NGINX “

Alternativ können Sie alle auf Ingress- NGINX-basierten ALBs deaktivieren, wodurch die Domain-Zuordnungen automatisch aktualisiert werden.

  1. Listen Sie alle ALBs auf und identifizieren Sie diejenigen, die auf Ingress- NGINX s basieren.
    ibmcloud ks ingress alb ls --cluster CLUSTER_NAME
  2. Deaktivieren Sie jeden Ingress- NGINX-ALB.
    ibmcloud ks ingress alb disable --alb NGINX_ALB_ID --cluster CLUSTER_NAME
  3. Stellen Sie sicher, dass Ihre Domain nun auf die Traefik-ALBs verweist.
    ibmcloud ks ingress domain ls --cluster CLUSTER_NAME

Option 3: ALB-IP-Adressen beibehalten

Wenn Ihre Kunden eine direkte Verbindung zu den IP-Adressen des ALB herstellen, anstatt DNS-Namen zu verwenden, können Sie diese IP-Adressen während der Migration beibehalten. Um IP-Adressen beizubehalten, müssen ALBs vorübergehend deaktiviert werden, was zu einer kurzen Dienstunterbrechung führt.

Beim Deaktivieren und erneuten Aktivieren eines ALB bleibt dessen ursprüngliche IP-Adresse erhalten, es sei denn, diese IP-Adresse wurde bereits von anderen Diensten belegt.

  1. Listen Sie alle ALBs auf und ermitteln Sie die auf Ingress- NGINX s basierenden, um deren IDs und IP-Adressen zu ermitteln.

    ibmcloud ks ingress alb ls --cluster CLUSTER_NAME

  2. Deaktivieren Sie den Ingress- NGINX-ALB. Dies führt zu einer kurzen Unterbrechung des Dienstes für den Datenverkehr unter dieser IP-Adresse.

    ibmcloud ks ingress alb disable --alb ALB_ID --cluster CLUSTER_NAME

  3. Aktivieren Sie den ALB mit einer Traefik-Version erneut, um dieselbe IP-Adresse weiterzuverwenden.

    ibmcloud ks ingress alb enable classic --alb ALB_ID --version TRAEFIK_VERSION --cluster CLUSTER_NAME

    Alternativ können Sie eine neue ALB erstellen und das Flag „ --ip “ verwenden, um die ursprüngliche IP-Adresse wiederzuverwenden.

  4. Aktualisieren Sie Ihre Ingress-Ressourcen, damit die Traefik-Ingress-Klasse verwendet wird. Wenn in Ihren Ressourcen die Ingress-Klasse explizit festgelegt ist, ändern Sie „ spec.ingressClassName “ von „ public-iks-k8s-nginx “ in „ public-iks-traefik “ (bzw. bei privaten ALBs von „ private-iks-k8s-nginx “ in „ private-iks-traefik “).

  5. Wenden Sie die aktualisierten Ingress-Ressourcen an.

    kubectl apply -f ingress.yaml

  6. Stellen Sie sicher, dass Ihre Anwendungen über den Traefik-Controller erreichbar sind.

    curl https://<domain>/<app_path>

VPC-Cluster

Bei VPC-Clustern aktualisieren Sie das Backend des Load Balancers so, dass Traefik anstelle von Ingress verwendet wird – NGINX.

Option 1: Das Backend des Load Balancers aktualisieren

  1. Aktualisieren Sie den Load Balancer so, dass er das Traefik-Backend verwendet.
    ibmcloud ks ingress load-balancer backend set --cluster CLUSTER_NAME --public-backend traefik [--private-backend traefik]
  2. Überprüfen Sie die Konfiguration des Lastenausgleichs.
    ibmcloud ks ingress load-balancer get --cluster CLUSTER_NAME
  3. Testen Sie Ihre Anwendungen, um sicherzustellen, dass sie nun von Traefik bereitgestellt werden.

Option 2: Deaktivieren der ALBs „Ingress- NGINX “

Alternativ können Sie alle auf Ingress- NGINX-basierten ALBs deaktivieren.

  1. Listen Sie alle ALBs auf und identifizieren Sie diejenigen, die auf Ingress- NGINX s basieren.
    ibmcloud ks ingress alb ls --cluster CLUSTER_NAME
  2. Deaktivieren Sie jeden Ingress- NGINX-ALB.
    ibmcloud ks ingress alb disable --alb NGINX_ALB_ID --cluster CLUSTER_NAME
  3. Stellen Sie sicher, dass der Load Balancer nun die Traefik-ALBs verwendet.
    ibmcloud ks ingress load-balancer get --cluster CLUSTER_NAME

Tasks nach der Migration

Führen Sie nach der Migration zu Traefik die folgenden Aufgaben durch:

  1. Überwachen Sie Ihre Anwendungen nach der Migration auf unerwartetes Verhalten oder Fehler.

  2. Aktualisiere die interne Dokumentation, um die neue Ingress-Konfiguration mit Traefik widerzuspiegeln.

  3. Entfernen Sie alle Test-ALBs, Domänen oder Ingress-Ressourcen, die nicht mehr benötigt werden.

  4. Nachdem Sie sich vergewissert haben, dass Traefik wie erwartet funktioniert, deaktivieren Sie die verbleibenden Ingress- NGINX-ALBs.

    ibmcloud ks ingress alb disable --alb NGINX_ALB_ID --cluster CLUSTER_NAME

Fehlerbehebung

Sollten während oder nach der Migration Probleme auftreten, befolgen Sie die folgenden Schritte, um diese zu diagnostizieren und zu beheben.

Ingress-Klasse prüfen

Stellen Sie sicher, dass die Ingress-Ressourcen die richtige Traefik-Klasse verwenden (public-iks-traefik oder private-iks-traefik).

ALB-Status überprüfen

Stellen Sie sicher, dass sich Ihre Traefik-ALBs in einem einwandfreien Zustand befinden.

ibmcloud ks ingress alb ls --cluster CLUSTER_NAME
Ingress-Status prüfen

Überprüfen Sie den Status Ihrer Ingress-Ressourcen.

kubectl get ingress -A
Protokolle überprüfen

Überprüfen Sie die Protokolle des Traefik-Controllers auf Fehler.

kubectl logs -n kube-system -l alb-image-type=traefik
Diagnose ausführen

Nutzen Sie den Ingress-Statusbericht, um Probleme zu identifizieren.

ibmcloud ks ingress status-report get --cluster CLUSTER_NAME
Bei Bedarf zurücksetzen

Sollten kritische Probleme auftreten, führen Sie ein Rollback auf Ingress- NGINX durch, indem Sie den Traefik-ALB deaktivieren und den Ingress- NGINX-ALB in seiner ursprünglichen Version wieder aktivieren. Planen Sie, die Probleme zu beheben und die Migration erneut durchzuführen.

Weitere Hilfe finden Sie unter „Fehlerbehebung bei Ingress“ oder wenden Sie sich an den IBM Cloud-Support.