Anthos Clusters on VMware heißt 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.

Nutzercluster-Migration zu empfohlenen Funktionen planen

Übersicht

Auf dieser Seite erfahren Sie, wie Sie Nutzercluster der Version 1.30 oder höher zu den folgenden empfohlenen Funktionen migrieren:

Migrieren Sie zu Dataplane V2 als Container Network Interface (CNI).
Nutzercluster mit kubeception zu Controlplane V2 migrieren
Konfiguration des Load Balancers migrieren:
- Von der Konfiguration des integrierten F5 BIG-IP-Load Balancers zu ManualLB
  
  oder
- Vom gebündelten Seesaw-Load Balancer zu MetalLB

Diese Seite richtet sich an IT-Administratoren und ‑Betreiber, die den Lebenszyklus der zugrunde liegenden technischen Infrastruktur verwalten. Informationen zu den gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud -Inhalten verweisen, finden Sie unter Häufig verwendete GKE Enterprise-Nutzerrollen und -Aufgaben.

Best Practices

Wir empfehlen, zuerst die am wenigsten kritische Umgebung zu migrieren, z. B. die Testumgebung. Nachdem Sie bestätigt haben, dass die Migration erfolgreich war, wiederholen Sie diesen Vorgang für jede Umgebung. Migrieren Sie zuletzt die Produktionsumgebung. So können Sie den Erfolg jeder Migration prüfen und dafür sorgen, dass Ihre Arbeitslasten ordnungsgemäß ausgeführt werden, bevor Sie zur nächsten, kritischeren Umgebung übergehen.

Wir empfehlen Ihnen, einen neuen Nutzercluster zu erstellen, für den Controlplane V2 aktiviert ist, um mehr über die architektonischen Unterschiede zu kubeception-Clustern zu erfahren. Der neue Cluster hat keine Auswirkungen auf Ihre Arbeitslasten. Im schlimmsten Fall, wenn die Migration fehlschlägt, haben Sie jedoch einen Cluster für Ihre Arbeitslasten bereit.

Weitere Informationen zur Migrationsplanung finden Sie unter Clustermigration zu empfohlenen Funktionen planen.

Voraussetzungen

Bei dieser Migration:

Der Nutzercluster muss mindestens Version 1.30 haben.
Alle Knotenpools müssen dieselbe Version wie der Nutzercluster haben.
Wenn im Cluster der Seesaw-Load Balancer verwendet wird, darf er nicht wie im nächsten Abschnitt beschrieben für die Beibehaltung der Client-IP-Adresse verwendet werden.

Beibehalten der Seesaw-Client-IP

Führen Sie zum Prüfen des externalTrafficPolicy den folgenden Befehl aus:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get svc -A -o yaml | grep "externalTrafficPolicy: Local"

Wenden Sie sich in diesem Fall an den Google-Support.

Zeitaufwand schätzen und Wartungsfenster planen

Wenn Sie den Cluster aktualisieren, werden standardmäßig alle Knotenpools parallel aktualisiert. Innerhalb der einzelnen Knotenpools werden die Knoten jedoch nacheinander aktualisiert. Die Gesamtaktualisierungszeit hängt daher von der Anzahl der Knoten im größten Knotenpool ab. So berechnen Sie einen groben Schätzwert für jedes Update:

Wenn Sie von Seesaw zu MetalLB migrieren, dauert es etwa 15 Minuten, bis der Knotenpool für den MetalLB-Load Balancer ausgewählt ist. Bei dieser Aktualisierung wird nur der ausgewählte Knotenpool aktualisiert.
Für alle anderen Aktualisierungen während der Migration multiplizieren Sie 15 Minuten mit der Anzahl der Knoten im Knotenpool.

Um den Zeitaufwand zu schätzen, zählen Sie, wie oft Sie den Cluster aktualisieren müssen. In den folgenden allgemeinen Schritten wird beschrieben, wann Sie gkectl update cluster ausführen müssen, um den Cluster zu aktualisieren:

Wenn im Nutzercluster die Always-On-Secrets-Verschlüsselung verwendet wird, deaktivieren Sie die Funktion und führen Sie gkectl update cluster aus.
Wenn enableDataplaneV2 für den Nutzercluster nicht festgelegt oder auf false gesetzt ist, nehmen Sie die Konfigurationsänderungen vor und führen Sie dann gkectl update cluster aus, um zu Dataplane V2 zu migrieren.
Bereiten Sie die Migration des Load Balancers und der Control Plane vor:
1. Wenn für den Administratorcluster die automatische Reparatur aktiviert ist, deaktivieren Sie sie. Führen Sie gkectl update admin aus. Dieses Update ist schnell abgeschlossen, da die Admin-Clusterknoten nicht neu erstellt werden.
2. Wenn der Nutzercluster Seesaw verwendet, wählen Sie einen Knotenpool für den MetalLB-Load Balancer aus und führen Sie dann gkectl update cluster aus. Durch diese Aktualisierung werden nur die Knoten im ausgewählten Knotenpool aktualisiert.
Nehmen Sie alle erforderlichen Konfigurationsänderungen vor, um Ihren Load Balancer zu aktualisieren und zu Controlplane V2 zu migrieren. Führen Sie gkectl update cluster aus.
Wenn Sie die Always-On-Secrets-Verschlüsselung nach der Migration deaktiviert haben, aktivieren Sie die Funktion wieder und führen Sie gkectl update cluster aus.

Die Gesamtdauer der Migration hängt davon ab, wie oft Sie gkectl cluster update ausführen müssen. Das wiederum hängt von Ihrer Konfiguration ab. Angenommen, Sie migrieren zu Dataplane V2, ControlPlane V2 und MetalLB. Angenommen, es gibt 10 Knoten im größten Knotenpool und 3 Knoten im Knotenpool, der von MetalLB verwendet wird. Um eine Schätzung für die Migrationszeit zu berechnen, fügen Sie Folgendes hinzu:

150 Minuten für die Migration zu Dataplane V2, da 15 Minuten × 10 Knoten im größten Pool = 150 Minuten.
45 Minuten für den von MetalLB verwendeten Knotenpool, da 15 Minuten × 3 Knoten in diesem Knotenpool = 45 Minuten.
150 Minuten für die Controlplane V2- und MetalLB-Aktualisierung, da 15 Minuten × 10 Knoten im größten Pool = 150 Minuten.

Die Migration dauert insgesamt etwa 345 Minuten, was 5 Stunden und 45 Minuten entspricht.

Bei Bedarf können Sie die Migration in mehreren Schritten ausführen. Im vorherigen Beispiel können Sie die Migration zu Dataplane V2 in einem Wartungsfenster und den Rest der Migration in einem oder zwei Wartungsfenstern durchführen.

Ausfallzeiten während der Migration planen

Planen Sie bei der Migration die folgenden Arten von Ausfallzeiten:

Ausfallzeit der Steuerungsebene: Der Zugriff auf den Kubernetes API-Server ist während der Migration beeinträchtigt. Wenn Sie zu Controlplane V2 migrieren, kommt es bei der Migration der loadBalancer.vips.controlPlaneVIP zu einer Ausfallzeit der Steuerungsebene für kubeception-Nutzercluster. Die Ausfallzeit beträgt in der Regel weniger als 10 Minuten. Sie hängt jedoch von Ihrer Infrastruktur ab.
Ausfallzeit des Arbeitsloads: Die von Diensten vom Typ „LoadBalancer“ verwendeten virtuellen IP-Adressen (VIPs) sind nicht verfügbar. Dies tritt nur bei einer Migration von Seesaw zu MetalLB auf. Während der MetalLB-Migration werden die Netzwerkverbindungen zu allen VIPs im Nutzercluster für Kubernetes-Dienste vom Typ LoadBalancer für etwa zwei bis zehn Minuten angehalten. Nach Abschluss der Migration funktionieren die Verbindungen wieder.

In der folgenden Tabelle werden die Auswirkungen der Migration beschrieben:

Von	Bis	Kubernetes API-Zugriff	Nutzerarbeitslasten
Kubeception-Cluster mit Calico, bei dem `enableDataplaneV2` nicht festgelegt oder auf `false` gesetzt ist	Kubeception-Cluster mit Dataplane V2	Nicht betroffen	Nicht betroffen
Kubeception-Cluster, bei dem `enableControlplaneV2` nicht festgelegt oder auf `false` mit `MetalLB` oder `ManualLB` festgelegt ist	Controlplane V2-Cluster mit derselben Art von Load Balancer	Betroffen	Nicht betroffen
Kubeception-Cluster mit `loadBalancer.kind: "F5BigIP"`	Controlplane V2-Cluster mit manueller Load Balancer-Konfiguration	Betroffen	Nicht betroffen
Kubeception-Cluster mit `loadBalancer.kind: "Seesaw"`	Controlplane V2-Cluster mit MetalLB	Betroffen	Betroffen

Betroffen: Während der Migration kommt es zu einer wahrnehmbaren Dienstunterbrechung.
Nicht betroffen: Es kommt entweder zu keiner Dienstunterbrechung oder sie ist fast nicht wahrnehmbar.

Migration vorbereiten

Führen Sie die Schritte in den folgenden Abschnitten aus, um eine erfolgreiche Migration zu ermöglichen.

Neue IP-Adressen zuweisen

Wenn Sie zu Steuerungsebene v2 migrieren, weisen Sie neue statische IP-Adressen im selben VLAN wie die Worker-Knoten (die Knoten in Knotenpools) zu.

Sie benötigen eine IP-Adresse für die loadBalancer.vips.controlPlaneVIP.
Weisen Sie jedem Knoten der Steuerungsebene eine IP-Adresse zu. Die Anzahl der IP-Adressen, die Sie zuweisen müssen, hängt davon ab, ob der Nutzercluster hochverfügbar (HA) oder nicht hochverfügbar ist.
- Ohne HA: eine IP-Adresse
- HA: drei IP-Adressen

Firewallregeln aktualisieren

Wenn Sie zu Controlplane V2 migrieren, aktualisieren Sie die Firewallregeln in Ihren Nutzerclustern. Achten Sie darauf, dass die neu zugewiesenen IP-Adressen für die Knoten der Steuerungsebene im Nutzercluster alle erforderlichen APIs und anderen Ziele erreichen können, wie unter Firewallregeln für Nutzerclusterknoten beschrieben.

Cluster- und Knotenpoolversionen prüfen

Prüfen Sie, ob alle Knotenpools dieselbe Version wie der Nutzercluster verwenden. Diese muss mindestens Version 1.30 sein. Andernfalls aktualisieren Sie die Knotenpools auf gkeOnPremVersion in der Konfigurationsdatei des Nutzerclusters, bevor Sie mit der Migration fortfahren. Führen Sie den folgenden Befehl aus, um die Versionen zu prüfen:

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

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

Clusterstatus prüfen

Prüfen Sie den Clusterstatus und beheben Sie alle Probleme, die vom Befehl gkectl diagnose cluster gemeldet werden:

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

Ersetzen Sie Folgendes:

ADMIN_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters
USER_CLUSTER_NAME: Der Name des Nutzerclusters.

Automatische Reparatur im Administratorcluster deaktivieren

Wenn Sie den Nutzercluster zu Controlplane V2 migrieren und die automatische Reparatur im Administratorcluster aktiviert ist, deaktivieren Sie die automatische Reparatur. Prüfen Sie das Feld autoRepair.enabled in der Konfigurationsdatei des Administratorclusters. Wenn dieses Feld nicht festgelegt oder auf true gesetzt ist, gehen Sie so vor:

Legen Sie in der Administrator-Clusterkonfigurationsdatei autoRepair.enabled auf false fest: Beispiele:
```
autoRepair:
  enabled: false
```

Aktualisieren Sie den Administratorcluster:

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

Ersetzen Sie Folgendes:

ADMIN_CLUSTER_KUBECONFIG: Pfad zur kubeconfig-Datei des Administratorclusters.
ADMIN_CLUSTER_CONFIG: der Pfad zur Konfigurationsdatei des Administratorclusters.

Aktivieren Sie nach Abschluss der Migration die automatische Reparatur im Administratorcluster wieder.

Prüfen, ob ein Problem mit der Always-On-Secrets-Verschlüsselung vorliegt

Wenn Sie den Nutzercluster zu Controlplane V2 migrieren, prüfen Sie, ob ein Problem mit der Always-On-Secrets-Verschlüsselung vorliegt.

Wenn die Always-On-Secrets-Verschlüsselung im Nutzercluster schon einmal aktiviert war, müssen Sie vor Beginn der Migration die Schritte unter Always-On-Secrets-Verschlüsselung deaktivieren und Secrets entschlüsseln ausführen. Andernfalls kann der neue Controlplane V2-Cluster keine Secrets entschlüsseln.

Führen Sie vor Beginn der Migration den folgenden Befehl aus, um zu prüfen, ob die Always-On-Secrets-Verschlüsselung schon einmal aktiviert wurde:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  get onpremusercluster USER_CLUSTER_NAME \
  -n USER_CLUSTER_NAME-gke-onprem-mgmt \
  -o jsonpath={.spec.secretsEncryption}

Wenn die Ausgabe des vorherigen Befehls leer ist, wurde die Always-On-Secrets-Verschlüsselung nie aktiviert. Sie können mit der Migration beginnen.

Wenn die Ausgabe des vorherigen Befehls nicht leer ist, wurde die Always-On-Secrets-Verschlüsselung zuvor aktiviert. Bevor Sie mit der Migration beginnen, müssen Sie die Schritte im nächsten Abschnitt ausführen, damit der neue Controlplane V2-Cluster Secrets entschlüsseln kann.

Das folgende Beispiel zeigt eine nicht leere Ausgabe:

{"generatedKeyVersions":{"keyVersions":[1]}}

Always-On-Secret-Verschlüsselung deaktivieren und Secrets bei Bedarf entschlüsseln

So deaktivieren Sie die Always-On-Secret-Verschlüsselung und entschlüsseln Secrets:

Wenn Sie die Verschlüsselung von Always-On-Secrets in der Konfigurationsdatei des Nutzerclusters deaktivieren möchten, fügen Sie dem Abschnitt secretsEncryption das Feld disabled: true hinzu:
```
secretsEncryption:
    mode: GeneratedKey
    generatedKey:
        keyVersion: KEY_VERSION
        disabled: true
```
Aktualisieren Sie den Cluster:
```
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

So führen Sie ein Rolling Update für ein bestimmtes DaemonSet aus:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  rollout restart statefulsets kube-apiserver \
  -n USER_CLUSTER_NAME

Rufen Sie die Manifeste aller Secrets im Nutzercluster im YAML-Format ab:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  get secrets -A -o yaml > SECRETS_MANIFEST.yaml

Damit alle Secrets in etcd im Klartext gespeichert werden, wenden Sie alle Secrets im Nutzercluster noch einmal an:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  apply -f SECRETS_MANIFEST.yaml
```
Sie können jetzt mit der Migration zu Controlplane V2 beginnen. Nach Abschluss der Migration können Sie die Always-On-Secrets-Verschlüsselung wieder im Cluster aktivieren.

Knotenpool für die Verwendung durch MetalLB aktivieren

Wenn Sie vom gebündelten Seesaw-Load Balancer zu MetalLB migrieren, führen Sie die Schritte in diesem Abschnitt aus. Der Cluster verwendet Seesaw, wenn loadBalancer.kind: Seesaw in der Konfigurationsdatei des Nutzerclusters enthalten ist. Wenn Sie die integrierte F5 BIG-IP-Konfiguration migrieren, fahren Sie mit dem nächsten Abschnitt Zu Dataplane V2 migrieren fort.

Wählen Sie einen Knotenpool aus und aktivieren Sie ihn für die Verwendung mit MetalLB. Bei der Migration wird MetalLB auf den Knoten in diesem Knotenpool bereitgestellt.

Wählen Sie in der Konfigurationsdatei des Nutzerclusters im Abschnitt nodePools einen Knotenpool aus oder fügen Sie einen neuen Knotenpool hinzu und legen Sie enableLoadBalancer auf true fest. Beispiele:
```
nodePools:
  - name: pool-1
    replicas: 3
    enableLoadBalancer: true
```

Aktualisieren Sie den Cluster:

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

Weitere Informationen zu MetalLB finden Sie unter Gebündeltes Load Balancing mit MetalLB.

Zu Dataplane V2 migrieren

Prüfen Sie vor der Migration, ob DataPlane V2 im Cluster aktiviert ist. Führen Sie dazu den folgenden Befehl aus:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get onpremusercluster USER_CLUSTER_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt -o yaml | grep enableDataplaneV2

Wenn Dataplane V2 bereits aktiviert ist, fahren Sie mit dem nächsten Abschnitt Vorbereitung auf die Load Balancer-Migration fort.

Für die Migration zu Dataplane V2 haben Sie folgende Möglichkeiten:

Aktualisieren Sie den Cluster auf Version 1.31. Eine detaillierte Anleitung finden Sie unter Dataplane V2 aktivieren.
Aktualisieren Sie den Cluster 1.30.

In beiden Fällen müssen Sie die NetworkPolicy-Spezifikation vorübergehend entfernen, wie in den folgenden Schritten beschrieben.

Führen Sie die folgenden Schritte aus, um zu Dataplane V2 zu migrieren. Wenn Sie Bedenken bezüglich der vorübergehenden Entfernung der NetworkPolicy-Spezifikation haben, wenden Sie sich an den Google-Support.

Wenn in Ihrem Cluster eine NetworkPolicy verwendet wird, entfernen Sie die zugehörige Spezifikation vorübergehend aus dem Cluster. Gehen Sie dazu so vor:

Prüfen Sie, ob auf Ihren Cluster eine nicht systemeigene NetworkPolicy angewendet wird:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy -A -o wide | grep -v kube-system

Wenn die Ausgabe des vorherigen Schritts nicht leer war, speichern Sie jede NetworkPolicy-Spezifikation in einer Datei, damit Sie die Spezifikation nach dem Aktualisieren des Clusters noch einmal anwenden können.
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE -o yaml > NETWORK_POLICY_NAME.yaml
```
Ersetzen Sie Folgendes:
- NETWORK_POLICY_NAME: Der Name der NetworkPolicy, die Sie speichern.
- NETWORK_POLICY_NAMESPACE: der Namespace des NetworkPolicy.

Löschen Sie die NetworkPolicy mit dem folgenden Befehl:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE

So migrieren Sie zu Dataplane V2:

Legen Sie in der Konfigurationsdatei für den Nutzercluster enableDataplaneV2 auf true fest.

Aktualisieren Sie Ihren Cluster, um DataPlane V2 zu aktivieren:

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

Wenn Sie in einem vorherigen Schritt nicht systemeigene NetworkPolicy-Spezifikationen entfernt haben, wenden Sie sie nach Abschluss des Updates mit dem folgenden Befehl wieder an:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f NETWORK_POLICY_NAME.yaml
```

Nach Abschluss dieser Schritte ist Dataplane V2 aktiviert. Als Nächstes bereiten Sie die Migration Ihres Clusters auf den empfohlenen Load Balancer und die Controlplane V2 vor.

Load Balancer-Migration vorbereiten

Wenn Ihre Nutzercluster den Seesaw-Load Balancer oder den integrierten F5 BIG-IP verwenden, folgen Sie der Anleitung in diesem Abschnitt, um die erforderlichen Änderungen an der Konfigurationsdatei des Nutzerclusters vorzunehmen. Andernfalls fahren Sie mit dem nächsten Abschnitt Migration auf Controlplane V2 vorbereiten fort.

F5 BIG-IP

Wenn Ihre Cluster die integrierte F5 BIG-IP-Konfiguration verwenden, bereiten Sie die Migration zu ManualLB vor, indem Sie die folgenden Änderungen an der Konfigurationsdatei des Nutzerclusters vornehmen:

Ändern Sie loadBalancer.kind in "ManualLB".
Behalten Sie für das Feld loadBalancer.vips.ingressVIP denselben Wert bei.
Wenn Sie zu Steuerungsebene V2 migrieren, ändern Sie den Wert des Felds loadBalancer.vips.controlPlaneVIP in die von Ihnen zugewiesene IP-Adresse. Andernfalls können Sie denselben Wert beibehalten.
Löschen Sie den gesamten Abschnitt loadBalancer.f5BigIP.

Die folgende Beispielkonfigurationsdatei für den Nutzercluster zeigt diese Änderungen:

loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.5
  ingressVIP: 198.51.100.20
kind: "f5BigIP" "ManualLB"
f5BigIP:
  address: "203.0.113.2"
  credentials:
  fileRef:
    path: "my-config-folder/user-creds.yaml"
    entry: "f5-creds"
  partition: "my-f5-user-partition"

Seesaw

Wenn Ihre Nutzercluster den Seesaw-Load Balancer verwenden, führen Sie die Schritte in den folgenden Abschnitten aus, um die Migration zu MetalLB vorzubereiten.

Adresspools angeben

Der MetalLB-Controller führt eine IP-Adressverwaltung für Dienste durch. Wenn ein Anwendungsentwickler einen Dienst vom Typ LoadBalancer in einem Nutzercluster erstellt, muss er keine IP-Adresse für den Dienst manuell angeben. Stattdessen wählt der MetalLB-Controller eine IP-Adresse aus einem von Ihnen angegebenen Adresspool aus.

Berücksichtigen Sie die maximale Anzahl von LoadBalancer-Diensten, die in Ihrem Nutzercluster wahrscheinlich aktiv sind. Geben Sie dann im Abschnitt loadBalancer.metalLB.addressPools der Konfigurationsdatei des Nutzerclusters genügend IP-Adressen an, um diese Dienste zu verarbeiten.

Geben Sie bei der Angabe von Adresspools die Ingress-VIP für Ihren Nutzercluster in einem der Pools an. Dies liegt daran, dass der Ingress-Proxy von einem Dienst vom Typ LoadBalancer verfügbar gemacht wird.

Adressen müssen im CIDR-Format oder im Bereichsformat vorliegen. Wenn Sie eine einzelne Adresse angeben möchten, verwenden Sie ein CIDR vom Typ /32, z. B. 198.51.100.10/32.

Cluster-Konfigurationsdatei aktualisieren

Aktualisieren Sie die Clusterkonfigurationsdatei, indem Sie den Abschnitt „Seesaw“ entfernen und einen Abschnitt „MetalLB“ hinzufügen. Gehen Sie dazu so vor:

Setzen Sie loadBalancer.kind auf "MetalLB".
Sie können für das Feld loadBalancer.vips.ingressVIP denselben Wert beibehalten.
Fügen Sie die virtuelle IP-Adresse für eingehenden Traffic einem MetalLB-Adresspool hinzu.
Wenn Sie zu Steuerungsebene V2 migrieren, ändern Sie den Wert des Felds loadBalancer.vips.controlPlaneVIP in die von Ihnen zugewiesene IP-Adresse. Andernfalls können Sie denselben Wert beibehalten.
Entfernen Sie den Abschnitt loadBalancer.seesaw.
Fügen Sie einen loadBalancer.metalLB-Abschnitt hinzu.

Der folgende Abschnitt einer Konfigurationsdatei für einen Nutzercluster zeigt diese Änderungen und die MetalLB-Konfiguration von:

Adresspool für den MetalLB-Controller, aus dem Dienste vom Typ LoadBalancer ausgewählt und zugewiesen werden können. Die Ingress-VIP, in diesem Beispiel 198.51.100.10, befindet sich in diesem Pool im Bereichsformat, 198.51.100.10/32.
Die VIP, die für den Kubernetes API-Server des Nutzerclusters festgelegt wurde.
Die virtuelle IP-Adresse für eingehenden Traffic, die Sie für den Ingress-Proxy konfiguriert haben.
Ein Knotenpool, der für die Verwendung von MetalLB aktiviert ist. Bei der Migration wird MetalLB auf den Knoten in diesem Knotenpool bereitgestellt.

loadBalancer:
  vips:
    controlPlaneVIP: "198.51.100.50"
    ingressVIP: "198.51.100.10"
  kind: "MetalLB" "Seesaw"
  seesaw:
    ipBlockFilePath: "user-cluster-2-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  metalLB:
    addressPools:
      - name: "address-pool-1"
        addresses:
        - "198.51.100.10/32"
        - "198.51.100.80 - 198.51.100.89"

Migration auf die Controlplane V2 vorbereiten

Wenn für den Cluster die Steuerungsebene V2 nicht aktiviert ist:

Konfigurationsdatei des Nutzerclusters aktualisieren
Wenn im Cluster das manuelle Load Balancing (loadBalancer.kind: "ManualLB") verwendet wird, aktualisieren Sie auch die Konfiguration auf Ihrem Load Balancer.

Diese Schritte werden in den folgenden Abschnitten beschrieben.

Wenn für den Cluster bereits die Steuerungsebene V2 aktiviert ist, fahren Sie mit dem Abschnitt Nutzercluster migrieren fort.

Konfigurationsdatei des Nutzerclusters aktualisieren

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

enableControlplaneV2 auf „true“ festlegen.
Optional können Sie die Steuerungsebene für den Nutzercluster mit Controlplane V2 hochverfügbar (HA) machen. Wenn Sie von einem Nicht-HA- zu einem HA-Cluster wechseln möchten, ändern Sie masterNode.replicas von 1 zu 3.
Fügen Sie die statische (n) IP-Adresse(n) für die Knoten der Steuerungsebene des Nutzerclusters dem Abschnitt network.controlPlaneIPBlock.ips hinzu. Die IP-Adresse (n) für die Knoten der Steuerungsebene müssen sich im selben VLAN wie die Worker-Knoten befinden.
Geben Sie netmask und gateway im Abschnitt network.controlPlaneIPBlock ein.
Wenn der Abschnitt network.hostConfig leer ist, füllen Sie ihn aus.
Achten Sie darauf, dass im Feld loadBalancer.vips.controlPlaneVIP die neue IP-Adresse für die virtuelle IP der Steuerungsebene steht. Die IP-Adresse muss sich im selben VLAN wie die IP-Adressen der Steuerungsebene befinden.
Wenn für den Nutzercluster manuelles Load Balancing verwendet wird, setzen Sie loadBalancer.manualLB.controlPlaneNodePort und loadBalancer.manualLB.konnectivityServerNodePort auf 0. Sie sind nicht erforderlich, wenn die Steuerungsebene V2 aktiviert ist, müssen aber den Wert 0 haben.
Wenn im Nutzercluster das manuelle Load Balancing verwendet wird, konfigurieren Sie den Load Balancer wie im nächsten Abschnitt beschrieben.

Zuordnungen im Load Balancer bei Bedarf anpassen

Wenn in Ihrem Nutzercluster bereits manuelles Load Balancing verwendet wird, müssen Sie einige Zuordnungen auf Ihrem Load Balancer konfigurieren. Wenn Sie von der integrierten F5 BIG-IP-Konfiguration zum manuellen Load Balancing migrieren, müssen Sie keine Konfigurationsänderungen an Ihrem Load Balancer vornehmen und können mit dem nächsten Abschnitt Nutzercluster migrieren fortfahren.

Konfigurieren Sie für jede IP-Adresse, die Sie im Abschnitt network.controlPlaneIPBlock angegeben haben, die folgenden Zuordnungen in Ihrem Load Balancer für die Knoten der Steuerungsebene:

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

Diese Zuordnungen sind für alle Knoten im Nutzercluster erforderlich, sowohl für Knoten der Steuerungsebene als auch für Worker-Knoten. Da NodePorts auf dem Cluster konfiguriert sind, öffnet Kubernetes die NodePorts auf allen Clusterknoten, damit jeder Knoten im Cluster den Datenebenen-Traffic verarbeiten kann.

Nachdem Sie die Zuordnungen konfiguriert haben, überwacht der Load Balancer den Traffic an der IP-Adresse, die Sie für die virtuelle IP-Adresse für eingehenden Traffic des Nutzerclusters auf den Standard-HTTP- und HTTPS-Ports konfiguriert haben. Der Load Balancer leitet Anfragen an jeden Knoten im Cluster weiter. Nachdem eine Anfrage an einen der Clusterknoten weitergeleitet wurde, leitet das interne Kubernetes-Netzwerk die Anfrage an den Ziel-Pod weiter.

Nutzercluster migrieren

Prüfen Sie zuerst alle Änderungen, die Sie an der Konfigurationsdatei des Nutzerclusters vorgenommen haben. Alle Einstellungen für Load Balancer und die Steuerungsebene V2 sind unveränderlich, es sei denn, Sie aktualisieren den Cluster für die Migration.

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

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

Migration zur Steuerungsebene V2

Während der Migration zur Controlplane V2 führt das Update die folgenden Aktionen aus:

Erstellt die Steuerungsebene eines neuen Clusters mit aktivierter Steuerungsebene V2.
Stoppt die Kubernetes-Steuerungsebene des Kubeception-Clusters.
Erstellt einen etcd-Snapshot des kubeception-Clusters.
Schaltet die Knoten der Nutzercluster-Steuerungsebene des Kubeception-Clusters aus. Bis die Migration abgeschlossen ist, werden die Knoten nicht gelöscht, da dies eine Fehlerwiederherstellung durch Rückfall auf diesen kubeception-Cluster ermöglicht.
Die Clusterdaten werden in der neuen Steuerebene mit dem in einem früheren Schritt erstellten etcd-Snapshot wiederhergestellt.
Verbindet die Knotenpoolknoten des kubeception-Clusters mit der neuen Steuerungsebene, auf die über die neue controlPlaneVIP zugegriffen werden kann.
Der wiederhergestellte Nutzercluster wird so angepasst, dass er dem Endstatus des Clusters mit aktivierter Steuerungsebene V2 entspricht.

Wichtige Hinweise:

Während der Migration kommt es zu keinen Ausfallzeiten für Nutzercluster-Arbeitslasten.
Während der Migration kommt es zu einer kurzen Ausfallzeit für die Steuerungsebene des Nutzerclusters. Insbesondere ist die Steuerungsebene nicht verfügbar, zwischen dem Anhalten der Kubernetes-Steuerungsebene des Kubeception-Clusters und dem Abschluss der Verbindung der Knotenpoolknoten des Kubeception-Clusters mit der neuen Steuerungsebene. In Tests betrug diese Ausfallzeit weniger als 7 Minuten, die tatsächliche Dauer hängt jedoch von Ihrer Infrastruktur ab.
Am Ende der Migration werden die Knoten der Nutzercluster-Steuerungsebene der kubeception-Cluster gelöscht. Wenn für den Administratorcluster network.ipMode.type auf "static" festgelegt ist, können Sie einige der nicht verwendeten statischen IP-Adressen wiederverwenden. Mit kubectl get nodes -o wide können Sie die Knotenobjekte des Administratorclusters auflisten, um zu sehen, welche IP-Adressen verwendet werden. Wenn Sie diese IP-Adressen wiederverwenden möchten, entfernen Sie sie aus der Konfigurationsdatei des Administratorclusters und führen Sie gkectl update admin aus.

Nach der Migration

Führen Sie nach Abschluss des Updates die folgenden Schritte aus:

Prüfen Sie, ob Ihr Nutzercluster ausgeführt wird:

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Die Ausgabe sieht in etwa so aus:

cp-vm-1       Ready    control-plane,master   18m
cp-vm-2       Ready    control-plane,master   18m
cp-vm-3       Ready    control-plane,master   18m
worker-vm-1   Ready                           6m7s
worker-vm-2   Ready                           6m6s
worker-vm-3   Ready                           6m14s

Wenn Sie zu Controlplane V2 migriert sind, aktualisieren Sie die Firewallregeln in Ihrem Administratorcluster, um die Knoten der Steuerungsebene des Nutzerclusters „kubeception“ zu entfernen.
Wenn Sie die Verschlüsselung mit „immer aktiven“ Secrets deaktiviert haben, aktivieren Sie die Funktion wieder.
1. Entfernen Sie in der Konfigurationsdatei des Nutzerclusters das Feld disabled: true.
2. Aktualisieren Sie den Nutzercluster:
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG
```
Wenn Sie die automatische Reparatur im Administratorcluster deaktiviert haben, aktivieren Sie die Funktion wieder.
1. Legen Sie in der Administrator-Clusterkonfigurationsdatei autoRepair.enabled auf true fest:
2. Aktualisieren Sie den Cluster:
```
gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG
```

Load Balancer-Migration

Wenn Sie den Load Balancer migriert haben, prüfen Sie, ob die Load Balancer-Komponenten erfolgreich ausgeführt werden.

MetalLB-Migration

Wenn Sie zu MetalLB migriert sind, prüfen Sie, ob die MetalLB-Komponenten erfolgreich ausgeführt werden:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods \
    --namespace kube-system --selector app=metallb

Die Ausgabe zeigt Pods für den MetalLB-Controller und -Lautsprecher. Beispiele:

metallb-controller-744884bf7b-rznr9   1/1     Running
metallb-speaker-6n8ws                 1/1     Running
metallb-speaker-nb52z                 1/1     Running
metallb-speaker-rq4pp                 1/1     Running

Löschen Sie nach einer erfolgreichen Migration die ausgeschalteten Seesaw-VMs für den Nutzercluster. Sie finden die Seesaw-VM-Namen im vmnames-Abschnitt der Datei seesaw-for-[USERCLUSTERNAME].yaml in Ihrem Konfigurationsverzeichnis.

F5 BIG-IP-Migration

Nach der Migration zum manuellen Load Balancing wird der Traffic zu Ihren Clustern nicht unterbrochen. Das liegt daran, dass 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

Die erwartete Ausgabe sieht in etwa so aus:


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