Konfiguration für integriertes F5 BIG-IP migrieren

In diesem Dokument wird gezeigt, wie Sie die Konfigurationseinstellungen für Ihren integrierten F5 BIG-IP-Load-Balancer zum manuellen Load-Balancing-Modus migrieren.

Unterstützung für den F5 BIG-IP-Load-Balancer

In der Vergangenheit konnten Sie GKE on VMware für die Einbindung in F5 BIG-IP so konfigurieren: Wenn ein Entwickler einen Dienst vom Typ LoadBalancer erstellt und eine virtuelle IP-Adresse (VIP) für den Dienst angibt, konfiguriert GKE on VMware automatisch die VIP auf dem Load-Balancer.

Wir empfehlen, die Konfiguration zu aktualisieren, um neue und erweiterte Features wie Controlplane V2 zu aktivieren. Sie können Ihren F5 BIG-IP-Load-Balancer weiterhin verwenden, müssen jedoch die Einstellungen in Ihren Clusterkonfigurationsdateien für die Verwendung des manuellen Load-Balancings ändern.

Voraussetzungen

Für die Migration gelten die folgenden Anforderungen:

  • Der Administratorcluster und alle Nutzercluster müssen mindestens Version 1.29 sein.

  • Sie müssen statische IP-Adressen für Ihre Administrator- und Nutzerclusterknoten verwenden. Der IP-Adressierungstyp wird im Feld network.ipMode.type festgelegt und ist unveränderlich. Wenn dieses Feld auf DHCP gesetzt ist, können Sie die Cluster nicht migrieren.

Konfigurationsdatei des Nutzerclusters aktualisieren

Nehmen Sie die folgenden Änderungen an der Konfigurationsdatei des Nutzerclusters vor:

  1. Ändern Sie loadBalancer.kind in "ManualLB".

  2. Behalten Sie für die Felder loadBalancer.vips.controlPlaneVIP und loadBalancer.vips.ingressVIP dieselben Werte bei.

  3. Konfigurieren Sie die nodePort, die für HTTP-Traffic an die virtuelle IP-Adresse für eingehenden Traffic verwendet wird.

    1. Rufen Sie den aktuellen HTTP-Wert nodePort ab:

      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get svc istio-ingress -n gke-system -oyaml | grep http2 -A 1

      Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.

    2. Fügen Sie den Wert aus dem vorherigen Befehl in das Feld loadBalancer.manualLB.ingressHTTPNodePort ein. Beispiel:

      loadBalancer:
  manualLB:
    ingressHTTPNodePort: 30243

  4. Konfigurieren Sie die nodePort, die für HTTPS-Traffic an die virtuelle IP-Adresse für eingehenden Traffic verwendet wird:

    1. Aktuellen HTTPS-Wert für nodePort abrufen:

      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get svc istio-ingress -n gke-system -oyaml | grep https -A 1

    2. Fügen Sie den Wert aus dem vorherigen Befehl in das Feld loadBalancer.manualLB.ingressHTTPSNodePort ein. Beispiel:

      loadBalancer:
  manualLB:
    ingressHTTPSNodePort: 30879

  5. Konfigurieren Sie die nodePort für den Kubernetes API-Server:

    1. Rufen Sie den aktuellen Wert nodePort für den Kubernetes API-Server ab:

      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    get svc kube-apiserver -n USER_CLUSTER_NAME -oyaml | grep kube-apiserver-port -A 1

      Ersetzen Sie Folgendes:

      • ADMIN_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des admin-Clusters.

      • USER_CLUSTER_NAME ist der Name des Nutzerclusters.

    2. Fügen Sie den Wert aus dem vorherigen Befehl in das Feld loadBalancer.manualLB.controlPlaneNodePort ein. Beispiel:

      loadBalancer:
  manualLB:
    controlPlaneNodePort: 30968

  6. Konfigurieren Sie die nodePort für den Konnectivity-Server:

    1. Rufen Sie den aktuellen nodePort-Wert für den Konnectivity-Server ab:

      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    get svc kube-apiserver -n USER_CLUSTER_NAME -oyaml | grep konnectivity-server-port -A 1

    2. Fügen Sie den Wert aus dem vorherigen Befehl in das Feld loadBalancer.manualLB.konnectivityServerNodePort ein. Beispiel:

      loadBalancer:
  manualLB:
    konnectivityServerNodePort: 30563

  7. Löschen Sie den gesamten Abschnitt loadBalancer.f5BigIP.

  8. Führen Sie gkectl diagnose cluster aus und beheben Sie alle vom Befehl gefundenen Probleme.

    gkectl diagnose cluster \
    --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name=USER_CLUSTER_NAME

Aktualisieren Sie den Nutzercluster:

Führen Sie den folgenden Befehl aus, um den Cluster zu migrieren:

gkectl update cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

Ersetzen Sie Folgendes:

  • ADMIN_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters

  • USER_CLUSTER_CONFIG: der Pfad der Nutzercluster-Konfigurationsdatei.

Konfigurationsdatei des Administratorclusters aktualisieren

Nehmen Sie die folgenden Änderungen an der Konfigurationsdatei des Administratorclusters vor:

  1. Ändern Sie loadBalancer.kind in "ManualLB".

  2. Behalten Sie für das Feld loadBalancer.vips.controlPlaneVIP denselben Wert bei.

  3. Prüfen Sie den Wert des Felds adminMaster.replicas. Wenn der Wert 3 ist, ist der Administratorcluster hochverfügbar. Wenn der Wert 1 ist, hat der Administratorcluster keine Hochverfügbarkeit.

  4. Führen Sie die folgenden Schritte nur für Administratorcluster ohne Hochverfügbarkeit aus:

    1. Rufen Sie den Wert von nodePort für den Kubernetes API-Server ab:

      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    get svc kube-apiserver -n kube-system -oyaml | grep nodePort

      Ersetzen Sie ADMIN_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Administratorclusters.

    2. Fügen Sie den Wert aus dem vorherigen Befehl in das Feld loadBalancer.manualLB.controlPlaneNodePort ein. Beispiel:

      loadBalancer:
  manualLB:
    controlPlaneNodePort: 30968

  5. Prüfen Sie mit dem folgenden Befehl, ob das Add-on nodePort vorhanden ist:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    get deploy monitoring-operator -n kube-system -oyaml | grep admin-ingress-nodeport

    Wenn der vorherige Befehl einen Wert ausgibt, fügen Sie ihn dem Feld loadBalancer.manualLB.addonsNodePort hinzu. Beispiel:

    loadBalancer:
  manualLB:
    addonsNodePort: 31405

  6. Löschen Sie den gesamten Abschnitt loadBalancer.f5BigIP.

  7. Führen Sie gkectl diagnose cluster aus und beheben Sie alle vom Befehl gefundenen Probleme.

    gkectl diagnose cluster \
    --kubeconfig=ADMIN_CLUSTER_KUBECONFIG

Aktualisieren Sie den Administratorcluster:

Führen Sie den folgenden Befehl aus, um den Cluster zu aktualisieren:

gkectl update cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG

Ersetzen Sie Folgendes:

  • ADMIN_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters

  • ADMIN_CLUSTER_CONFIG: der Pfad der Konfigurationsdatei des Administratorclusters.

Prüfen, ob F5-Legacy-Ressourcen noch vorhanden sind

Nachdem Sie Ihre Cluster auf manuelles Load-Balancing aktualisiert haben, wird der Traffic zu Ihren Clustern nicht unterbrochen, da die vorhandenen F5-Ressourcen noch vorhanden sind, wie Sie mit dem folgenden Befehl feststellen können:

kubectl --kubeconfig CLUSTER_KUBECONFIG \
  api-resources --verbs=list -o name   | xargs -n 1 kubectl --kubeconfig CLUSTER_KUBECONFIG get --show-kind --ignore-not-found --selector=onprem.cluster.gke.io/legacy-f5-resource=true -A

Ersetzen Sie CLUSTER_KUBECONFIG entweder durch den Pfad des Administratorclusters oder der kubeconfig-Datei des Nutzerclusters.

Die erwartete Ausgabe sieht in etwa so aus:

Administratorcluster:

Warning: v1 ComponentStatus is deprecated in v1.19+
NAMESPACE     NAME                        TYPE     DATA   AGE
kube-system   secret/bigip-login-xt697x   Opaque   4      13h
NAMESPACE     NAME                              SECRETS   AGE
kube-system   serviceaccount/bigip-ctlr         0         13h
kube-system   serviceaccount/load-balancer-f5   0         13h
NAMESPACE     NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/k8s-bigip-ctlr-deployment   1/1     1            1           13h
kube-system   deployment.apps/load-balancer-f5            1/1     1            1           13h
NAME                                                                                ROLE                                       AGE
clusterrolebinding.rbac.authorization.k8s.io/bigip-ctlr-clusterrole-binding         ClusterRole/bigip-ctlr-clusterrole         13h
clusterrolebinding.rbac.authorization.k8s.io/load-balancer-f5-clusterrole-binding   ClusterRole/load-balancer-f5-clusterrole   13h
NAME                                                                 CREATED AT
clusterrole.rbac.authorization.k8s.io/bigip-ctlr-clusterrole         2024-03-25T04:37:34Z
clusterrole.rbac.authorization.k8s.io/load-balancer-f5-clusterrole   2024-03-25T04:37:34Z

Nutzercluster:

Warning: v1 ComponentStatus is deprecated in v1.19+
NAMESPACE     NAME                        TYPE     DATA   AGE
kube-system   secret/bigip-login-sspwrd   Opaque   4      14h
NAMESPACE     NAME                              SECRETS   AGE
kube-system   serviceaccount/bigip-ctlr         0         14h
kube-system   serviceaccount/load-balancer-f5   0         14h
NAMESPACE     NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/k8s-bigip-ctlr-deployment   1/1     1            1           14h
kube-system   deployment.apps/load-balancer-f5            1/1     1            1           14h
NAME                                                                                ROLE                                       AGE
clusterrolebinding.rbac.authorization.k8s.io/bigip-ctlr-clusterrole-binding         ClusterRole/bigip-ctlr-clusterrole         14h
clusterrolebinding.rbac.authorization.k8s.io/load-balancer-f5-clusterrole-binding   ClusterRole/load-balancer-f5-clusterrole   14h
NAME                                                                 CREATED AT
clusterrole.rbac.authorization.k8s.io/bigip-ctlr-clusterrole         2024-03-25T05:16:40Z
clusterrole.rbac.authorization.k8s.io/load-balancer-f5-clusterrole   2024-03-25T05:16:41Z

Load-Balancer prüfen

Nach der Migration sollten Sie keine Einstellungen im Load-Balancer ändern müssen, da Sie dieselben VIPs und nodePort-Werte beibehalten haben. In den folgenden Tabellen werden die Zuordnungen von VIPs zu Knoten-IP-Adressen beschrieben:nodePort.

Hochverfügbarkeits-Administratorcluster

Traffic zu Knoten der Steuerungsebene

GKE on VMware handhabt das Load-Balancing des Traffics der Steuerungsebene für Hochverfügbarkeits-Administratorcluster automatisch. Sie müssen zwar keine Zuordnung im Load-Balancer konfigurieren, aber Sie müssen im Feld loadBalancer.vips.controlPlaneVIP eine IP-Adresse angeben.

Traffic zu Diensten in den Add-on-Knoten

Wenn Ihr Administratorcluster einen Wert für addonsNodePort hatte, sollten Sie eine Zuordnung zu den IP-Adressen und den Wert nodePort für Traffic zu Diensten in Add-on-Knoten sehen:

  • (addonsVIP:8443) -> (NODE_IP_ADDRESSES:addonsNodePort)

Diese Zuordnung sollte für alle Knoten im Administratorcluster vorhanden sein, sowohl für die Knoten der Steuerungsebene als auch für die Add-on-Knoten.

Administratorcluster ohne Hochverfügbarkeit

Traffic der Steuerungsebene

Die folgende Abbildung zeigt die Zuordnung zur IP-Adresse und dem nodePort-Wert für den Knoten der Steuerungsebene:

  • (controlPlaneVIP:443) -> (NODE_IP_ADDRESSES:controlPlaneNodePort)

Diese Zuordnung sollte für alle Knoten im Administratorcluster vorhanden sein, sowohl für den Knoten der Steuerungsebene als auch für die Add-on-Knoten.

Traffic zu Diensten in den Add-on-Knoten

Wenn Ihr Administratorcluster einen Wert für addonsNodePort hat, sollten Sie die folgende Zuordnung zu den IP-Adressen und nodePort-Werten für Dienste haben, die in Add-on-Knoten ausgeführt werden:

  • (addonsVIP:8443) -> (NODE_IP_ADDRESSES:addonsNodePort)

Diese Zuordnung sollte für alle Knoten im Administratorcluster vorhanden sein, sowohl für den Knoten der Steuerungsebene als auch für die Add-on-Knoten.

Nutzercluster

Traffic der Steuerungsebene

Im Folgenden sehen Sie die Zuordnung zu den IP-Adressen und nodePort-Werten für den Traffic der Steuerungsebene:

  • (controlPlaneVIP:443) -> (NODE_IP_ADDRESSES:controlPlaneNodePort)
  • (controlPlaneVIP:8132) -> (NODE_IP_ADDRESSES:konnectivityServerNodePort)

Diese Zuordnung sollte für alle Knoten im admin-Cluster verfügbar sein, sowohl für den Administratorcluster als auch für die Knoten der Steuerungsebene des Nutzerclusters.

Traffic auf Datenebene

Im Folgenden sehen Sie die Zuordnung zu den IP-Adressen und nodePort-Werten für den Traffic der Datenebene:

  • (ingressVIP:80) -> (NODE_IP_ADDRESSES:ingressHTTPNodePort)
  • (ingressVIP:443) -> (NODE_IP_ADDRESSES:ingressHTTPSNodePort)