Konfigurationseinstellungen für den F5 BIG-IP-Load-Balancer migrieren

1.29: Vorabversion
1.28: Nicht verfügbar

In diesem Dokument wird gezeigt, wie Sie die Konfigurationseinstellungen für Ihre F5 BIG-IP-Load-Balancer-Integration in den manuellen Load-Balancing-Modus für Cluster mit Version 1.29 migrieren. Wenn Ihre Cluster Version 1.30 oder höher haben, empfehlen wir Ihnen, der Anleitung unter Clustermigration zu empfohlenen Funktionen planen zu folgen.

Wenn Sie F5 BIG-IP im Modus für manuelles Load-Balancing verwenden, können Sie Ihre F5-Agents unabhängig voneinander aktualisieren, ohne die Funktion Ihres F5-Load-Balancers oder Ihrer Kubernetes-Dienste zu beeinträchtigen. Wenn Sie zur manuellen Konfiguration migrieren, können Sie Updates direkt von F5 erhalten, um für eine optimale Leistung und Sicherheit zu sorgen.

Diese Migration ist in folgenden Fällen erforderlich:

  • Sie möchten neue Features wie Steuerungsebene V2 aktivieren und benötigen Zugriff auf F5.

  • Sie benötigen Funktionen, die von einem BIG-IP CIS-CIS-Controller (Container Ingress Services) nach Version 1.14 bereitgestellt werden.

Wenn die vorherigen Umstände nicht auf Sie zutreffen, können Sie die gebündelte Konfiguration für das F5 BIG-IP-Load-Balancing verwenden.

In beiden Fällen unterstützen wir F5 weiterhin offiziell als Load-Balancer-Lösung.

Versionsverwaltung für den F5 BIG-IP-Load Balancer

Wir unterstützen die Verwendung von F5 BIG-IP mit Load-Balancer-Agents, die aus den folgenden beiden Controllern bestehen:

  • F5 Controller (Pod-Präfix: load-balancer-f5): Gleicht Kubernetes Services vom Typ LoadBalancer mit dem ConfigMap-Format F5 Common Controller Core Library (CCCL) ab.

  • F5 BIG-IP CIS-Controller Version 1.14 (Pod-Präfix: k8s-bigip-ctlr-deployment): übersetzt ConfigMaps in F5-Load-Balancer-Konfigurationen.

Diese Agents optimieren die Konfiguration von F5-Load-Balancern in Ihrem Kubernetes-Cluster. Durch das Erstellen eines Service vom Typ LoadBalancer konfigurieren die Controller automatisch den F5-Load-Balancer, um Traffic an Ihre Clusterknoten weiterzuleiten.

Die gebündelte Lösung hat jedoch Einschränkungen:

  • Die Aussagekraft der Service API ist begrenzt. Sie können den BIG-IP-Controller nicht nach Belieben konfigurieren und keine erweiterten F5-Features verwenden. F5 bietet bereits nativ eine bessere Unterstützung der Service API.

  • Die Implementierung verwendet die Legacy-CCCL ConfigMap API und 1.x CIS. F5 bietet jedoch jetzt die neuere AS3 ConfigMap API und 2.x CIS.

Der CIS-Controller im Google Distributed Cloud-Bundle bleibt aufgrund von Kompatibilitätsproblemen mit dem F5-Upgrade-Leitfaden für CIS v2.x auf Version 1.14. Damit Sie Sicherheitslücken beheben und auf die neuesten Features zugreifen können, stellen wir die F5-Agents von der gebündelten Installation auf die unabhängige Installation um. Wenn Sie migrieren, können Sie die vorhandenen Agents ohne Unterbrechung weiter verwenden und Ihre zuvor erstellten Dienste bleiben funktionsfähig.

Bei neu erstellten Clustern für das manuelle Load-Balancing mit F5 als Load-Balancing-Lösung müssen Sie die Controller selbst installieren. Wenn Ihr Cluster von gebündeltem F5 migriert wurde und Sie eine neuere Version des CIS-Controllers verwenden möchten, müssen Sie die Controller selbst installieren.

Voraussetzungen

Für die Migration gelten die folgenden Anforderungen:

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

  • Sie müssen für Ihre Administrator- und Nutzerclusterknoten statische IP-Adressen 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 dem Feld loadBalancer.manualLB.ingressHTTPNodePort hinzu. 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. Rufen Sie den aktuellen HTTPS-Wert nodePort ab:

      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 dem Feld loadBalancer.manualLB.ingressHTTPSNodePort hinzu. Beispiel: 

      loadBalancer:
  manualLB:
    ingressHTTPSNodePort: 30879

  5. Konfigurieren Sie 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:

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

      • USER_CLUSTER_NAME: Name des Nutzerclusters.

    2. Fügen Sie den Wert aus dem vorherigen Befehl der loadBalancer.manualLB.controlPlaneNodePort-Feld. Beispiel:

      loadBalancer:
  manualLB:
    controlPlaneNodePort: 30968

  6. Konfigurieren Sie 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 dem Feld loadBalancer.manualLB.konnectivityServerNodePort hinzu. Beispiel: 

      loadBalancer:
  manualLB:
    konnectivityServerNodePort: 30563

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

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 Ihrer Nutzerclusterkonfigurationsdatei.

Konfigurationsdatei für den Administratorcluster 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 (HA). Wenn der Wert 1 ist, ist der Administratorcluster nicht hochverfügbar.

  4. Führen Sie die folgenden Schritte nur für nicht hochverfügbare Administratorcluster 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 der loadBalancer.manualLB.controlPlaneNodePort-Feld. Beispiel:

      loadBalancer:
  manualLB:
    controlPlaneNodePort: 30968

  5. Führen Sie den folgenden Befehl aus, um zu prüfen, ob ein 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 loadBalancer.manualLB.addonsNodePort-Feld hinzu. Beispiel:

    loadBalancer:
  manualLB:
    addonsNodePort: 31405

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

Aktualisieren Sie den Administratorcluster:

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

gkectl update admin \
    --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 Ihrer Administratorcluster-Konfigurationsdatei.

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

Nachdem Sie Ihre Cluster für die Verwendung des manuellen Load Balancing aktualisiert haben, wird der Traffic zu Ihren Clustern nicht unterbrochen, da die vorhandenen F5-Ressourcen noch vorhanden sind. Dies können Sie mit dem folgenden Befehl sehen:

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 durch den Pfad der kubeconfig-Datei des Administrator- oder 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 müssen Sie in der Regel keine Einstellungen im Load Balancer ändern, da Sie die gleichen VIPs und nodePort-Werte beibehalten haben. In dem folgenden Tabellen werden die Zuordnungen von VIPs zu Knoten-IP-Adressen beschrieben:nodePort.

HA-Administratorcluster

Traffic zu Knoten der Steuerungsebene

Google Distributed Cloud führt automatisch das Load Balancing des Traffics der Steuerungsebene für HA-Administratorcluster aus. 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 den Traffic zu Diensten in Add-on-Knoten sehen:

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

Sie sollten diese Zuordnung für alle Knoten im Administratorcluster haben, sowohl für die Knoten der Steuerungsebene als auch für die Add-on-Knoten.

Nicht-HA-Administratorcluster

Traffic der Steuerungsebene

Im Folgenden sehen Sie die Zuordnung zur IP-Adresse und zum nodePort-Wert für den Knoten der Steuerungsebene:

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

Sie sollten diese Zuordnung für alle Knoten im Administratorcluster haben; sowohl die Knoten der Steuerungsebene als auch 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)

Sie sollten diese Zuordnung für alle Knoten im Administratorcluster haben; sowohl die Knoten der Steuerungsebene als auch die Add-on-Knoten.

Nutzercluster

Traffic der Steuerungsebene

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

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

Sie sollten diese Zuordnung für alle Knoten im admin haben, also sowohl für den Administratorcluster als auch für die Knoten der Steuerungsebene des Nutzerclusters.

Traffic auf Datenebene

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

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