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

Vorschau

Diese Funktion unterliegt den Bedingungen für Pre‑GA-Angebote im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Funktionen sind „wie gesehen“ verfügbar und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie in den Beschreibungen der Produkteinführungsphasen.

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 der Version 1.29 migrieren. Wenn Ihre Cluster die 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.

Hinweis: Wenn Sie die Einstellungen in Ihren Clusterkonfigurationsdateien so ändern, dass das manuelle Load-Balancing für F5 BIG-IP verwendet wird, bedeutet dies nicht, dass das Load-Balancing manuell erfolgt. Sowohl beim gebündelten als auch beim manuellen F5-Load-Balancing können Sie die Load-Balancing-Konfiguration mithilfe von Load-Balancer-Agents automatisch verwalten.

Diese Migration ist in den folgenden Fällen erforderlich:

• Sie möchten neue Funktionen wie Controlplane V2 aktivieren und benötigen auch 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 oben genannten Umstände nicht auf Sie zutreffen, können Sie die gebündelte Konfiguration für das F5 BIG-IP-Load-Balancing weiterhin verwenden.

In jedem Fall 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-Dienste vom Typ LoadBalancer mit dem ConfigMap-Format der F5 Common Controller Core Library (CCCL) ab.

• F5 BIG-IP CIS Controller v1.14 (Pod-Präfix: k8s-bigip-ctlr-deployment): wandelt ConfigMaps in F5-Load-Balancer-Konfigurationen um.

Diese Agents vereinfachen die Konfiguration von F5-Load-Balancern in Ihrem Kubernetes-Cluster. Wenn Sie einen Dienst vom Typ LoadBalancer erstellen, konfigurieren die Controller den F5-Load-Balancer automatisch so, dass Traffic an Ihre Clusterknoten weitergeleitet wird.

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

• Die Aussagekraft der Service API ist begrenzt. Sie können den BIG-IP-Controller nicht beliebig konfigurieren oder erweiterte F5-Funktionen verwenden. F5 bietet bereits besseren Support für die Service API.

• Bei der Implementierung werden die alte CCCL ConfigMap API und CIS 1.x verwendet. F5 bietet jetzt jedoch die neuere AS3 ConfigMap API und 2.x CIS.

Der CIS-Controller im Google Distributed Cloud-Bundle ist aufgrund von Kompatibilitätsproblemen mit der F5-Upgradeanleitung für CIS v2.x auf v1.14 geblieben. Damit Sie Sicherheitslücken beheben und auf die neuesten Funktionen zugreifen können, werden die F5-Agents nicht mehr als gebündelte Komponenten, sondern unabhängig installiert. Wenn Sie migrieren, können Sie die vorhandenen Agents ohne Unterbrechung weiter verwenden und Ihre zuvor erstellten Dienste bleiben betriebsbereit.

Bei neu erstellten Clustern mit manuellem Load-Balancing und F5 als Load-Balancing-Lösung müssen Sie die Controller selbst installieren. Wenn Ihr Cluster von gebündelten F5-Produkten 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 Administratorclusters.

      • USER_CLUSTER_NAME: Name des Nutzerclusters.

   2. Fügen Sie den Wert aus dem vorherigen Befehl dem Feld loadBalancer.manualLB.controlPlaneNodePort hinzu. 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 dem Feld loadBalancer.manualLB.controlPlaneNodePort hinzu. 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 Administrator 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)

Hinweis: Die Systemdiagnose zu ingressVIP schlägt fehl, bis Sie mindestens einen Ingress konfigurieren.