Anthos-Cluster auf VMware ist jetzt Google Distributed Cloud (nur Software) für VMware. Weitere Informationen finden Sie in der Produktübersicht.

Diese Seite wurde von der Cloud Translation API übersetzt.

Konfiguration für integrierte 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 Google Distributed Cloud so konfigurieren, dass sie in F5 BIG-IP eingebunden wird: Wenn ein Entwickler einen Dienst vom Typ LoadBalancer erstellt und eine virtuelle IP-Adresse (VIP) für den Dienst angibt, konfiguriert Google Distributed Cloud automatisch die VIP auf dem Load-Balancer.

Wenn Sie neue und erweiterte Features wie Steuerungsebene V2 aktivieren möchten, empfehlen wir, die Konfiguration zu aktualisieren. Sie können den F5 BIG-IP-Load-Balancer weiterhin verwenden, müssen aber die Einstellungen in Ihren Clusterkonfigurationsdateien so ändern, dass manuelles Load-Balancing verwendet wird.

Nach der Migration bleiben Ihre F5-Arbeitslasten erhalten, aber sie werden nicht mehr von Google Distributed Cloud verwaltet. In einer zukünftigen Version wird F5 BIG-IP nur für die manuelle Verwaltung verfügbar sein. Dies bedeutet, dass Sie Ihre F5 BIG-IP-Arbeitslasten direkt verwalten müssen.

Voraussetzungen

Für die Migration gelten folgende Anforderungen:

Der Administratorcluster und alle Nutzercluster müssen Version 1.29 oder höher 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:

Ändern Sie loadBalancer.kind in "ManualLB".
Behalten Sie für die Felder loadBalancer.vips.controlPlaneVIP und loadBalancer.vips.ingressVIP dieselben Werte bei.
Konfigurieren Sie die nodePort, die für HTTP-Traffic verwendet wird, der an die virtuelle IP-Adresse für eingehenden Traffic gesendet 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 dem Feld loadBalancer.manualLB.ingressHTTPNodePort den Wert aus dem vorherigen Befehl hinzu. Beispiel:
```
loadBalancer:
  manualLB:
    ingressHTTPNodePort: 30243
```
Konfigurieren Sie die nodePort, die für HTTPS-Traffic verwendet wird, der an die virtuelle IP-Adresse für eingehenden Traffic gesendet wird:
1. Rufen Sie den aktuellen HTTPS-Wert für nodePort ab:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get svc istio-ingress -n gke-system -oyaml | grep https -A 1
```
2. Fügen Sie dem Feld loadBalancer.manualLB.ingressHTTPSNodePort den Wert aus dem vorherigen Befehl hinzu. Beispiel:
```
loadBalancer:
  manualLB:
    ingressHTTPSNodePort: 30879
```
Konfigurieren Sie die nodePort für den Kubernetes API-Server:
1. Rufen Sie den aktuellen nodePort-Wert 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 dem Feld loadBalancer.manualLB.controlPlaneNodePort den Wert aus dem vorherigen Befehl hinzu. Beispiel:
```
loadBalancer:
  manualLB:
    controlPlaneNodePort: 30968
```
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 dem Feld loadBalancer.manualLB.konnectivityServerNodePort den Wert aus dem vorherigen Befehl hinzu. Beispiel:
```
loadBalancer:
  manualLB:
    konnectivityServerNodePort: 30563
```
Löschen Sie den gesamten Abschnitt loadBalancer.f5BigIP.

Führen Sie gkectl diagnose cluster aus und beheben Sie alle durch den 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: Pfad der Konfigurationsdatei des Nutzerclusters.

Konfigurationsdatei des Administratorclusters aktualisieren

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

Ändern Sie loadBalancer.kind in "ManualLB".
Behalten Sie den Wert für das Feld loadBalancer.vips.controlPlaneVIP bei.
Prüfen Sie den Wert des Felds adminMaster.replicas. Wenn der Wert 3 ist, ist der Administratorcluster hochverfügbar. Wenn der Wert 1 ist, gilt der Administratorcluster nicht für Hochverfügbarkeit.
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 dem Feld loadBalancer.manualLB.controlPlaneNodePort den Wert aus dem vorherigen Befehl hinzu. Beispiel:
```
loadBalancer:
  manualLB:
    controlPlaneNodePort: 30968
```
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
```
Löschen Sie den gesamten Abschnitt loadBalancer.f5BigIP.
Führen Sie gkectl diagnose cluster aus und beheben Sie alle durch den 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: Pfad der Konfigurationsdatei des Administratorclusters.

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

Nachdem Sie Ihre Cluster für die Verwendung des manuellen Load-Balancings aktualisiert haben, wird der Traffic zu Ihren Clustern nicht unterbrochen, da die vorhandenen F5-Ressourcen noch vorhanden sind, wie Sie mit dem folgenden Befehl sehen 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 durch den Pfad der kubeconfig-Datei des Administratorclusters oder 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, da Sie die gleichen 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

Google Distributed Cloud verwaltet automatisch das Load-Balancing des Traffics der Steuerungsebene für Hochverfügbarkeits-Administratorcluster. Obwohl Sie keine Zuordnung im Load-Balancer konfigurieren müssen, geben Sie im Feld loadBalancer.vips.controlPlaneVIP eine IP-Adresse an.

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.

Administratorcluster ohne Hochverfügbarkeit

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 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 hatte, sollten Sie den IP-Adressen und den nodePort-Werten für Dienste, die in Add-on-Knoten ausgeführt werden, wie folgt zugeordnet werden:

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

Sie sollten diese Zuordnung für alle Knoten im Administratorcluster haben, 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)

Sie sollten diese Zuordnung für alle Knoten im admin-Cluster haben, 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 Traffic auf der Datenebene:

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