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

  • Load-Balancer-Konfiguration 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 und migrieren Sie Ihre Produktionsumgebung zuletzt. 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, wichtigeren Umgebung wechseln.

Wir empfehlen, einen neuen Nutzercluster mit aktiviertem Controlplane V2 zu erstellen, um die architektonischen Unterschiede zu Kubeception-Clustern kennenzulernen. Der neue Cluster hat keine Auswirkungen auf Ihre Arbeitslasten. Im schlimmsten Fall, wenn die Migration fehlschlägt, haben Sie jedoch einen Cluster, der für Ihre Arbeitslasten bereit ist.

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

Voraussetzungen

Für diese Migration:

  • Der Nutzercluster muss mindestens Version 1.30 haben.
  • Alle Knotenpools müssen dieselbe Version wie der Nutzercluster haben.
  • Wenn der Cluster den Seesaw-Load-Balancer verwendet, sollten Sie sich nicht auf Seesaw verlassen, um die Client-IP beizubehalten, wie im nächsten Abschnitt beschrieben.

Beibehalten der Client-IP-Adresse von Seesaw

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"

Wenn dieses Problem auftritt, wenden Sie sich 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 Gesamtzeit für ein Update hängt also von der Anzahl der Knoten im größten Knotenpool ab. So berechnen Sie eine grobe Schätzung für jedes Update:

  • Wenn Sie von Seesaw zu MetalLB migrieren, dauert es etwa 15 Minuten, bis Sie einen Knotenpool für den MetalLB-Load Balancer auswählen können. Bei dieser Aktualisierung wird nur der ausgewählte Knotenpool aktualisiert.
  • Bei allen anderen Updates im Migrationsprozess 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 Schritten wird gezeigt, wann Sie gkectl update cluster ausführen müssen, um den Cluster zu aktualisieren:

  1. Wenn der Nutzercluster die Always-On-Secrets-Verschlüsselung verwendet, deaktivieren Sie die Funktion und führen Sie gkectl update cluster aus.
  2. Wenn für den Nutzercluster enableDataplaneV2 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.

  3. Load-Balancer- und Steuerungsebenenmigration vorbereiten:

    1. Wenn im Administratorcluster die automatische Reparatur aktiviert ist, deaktivieren Sie sie. Führen Sie gkectl update admin aus. Dieses Update ist schnell abgeschlossen, da die Knoten des Administratorclusters 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 gkectl update cluster aus. Bei dieser Aktualisierung werden nur die Knoten im ausgewählten Knotenpool aktualisiert.

  4. Nehmen Sie alle erforderlichen Konfigurationsänderungen vor, um Ihren Load Balancer zu aktualisieren und zur Controlplane V2 zu migrieren. Führen Sie gkectl update cluster aus.

  5. Wenn Sie die Always-On-Secret-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, was wiederum von Ihrer Konfiguration abhängt. Angenommen, Sie migrieren zu Dataplane V2, Controlplane V2 und MetalLB. Angenommen, der größte Knotenpool hat 10 Knoten und der Knotenpool, den MetalLB verwenden wird, hat 3 Knoten. So berechnen Sie eine Schätzung für die Migrationsdauer:

  • 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 das Controlplane V2- und MetalLB-Update, da 15 Minuten × 10 Knoten im größten Pool = 150 Minuten.

Die Gesamtzeit für die Migration beträgt etwa 345 Minuten, was 5 Stunden und 45 Minuten entspricht.

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

Ausfallzeiten während der Migration einplanen

Planen Sie bei der Migration die folgenden Arten von Ausfallzeiten ein:

  • 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 Kubeception-Nutzerclustern zu Ausfallzeiten der Steuerungsebene, da die loadBalancer.vips.controlPlaneVIP migriert wird. Die Ausfallzeit beträgt in der Regel weniger als 10 Minuten, hängt aber von Ihrer Infrastruktur ab.
  • Ausfallzeiten von Arbeitslasten: 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. Durch die MetalLB-Migration werden Netzwerkverbindungen zu allen VIPs im Nutzercluster für Kubernetes-Dienste vom Typ LoadBalancer für etwa zwei bis zehn Minuten unterbrochen. 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, in dem enableControlplaneV2 nicht festgelegt oder auf false mit MetalLB oder ManualLB festgelegt ist. Controlplane V2-Cluster mit demselben Load-Balancer-Typ 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 kaum wahrnehmbar.

Migration vorbereiten

Führen Sie die Schritte in den folgenden Abschnitten aus, um eine erfolgreiche Migration zu gewährleisten.

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

    • Nicht HA: eine IP-Adresse
    • HA: drei IP-Adressen

Firewallregeln aktualisieren

Wenn Sie zu Controlplane V2 migrieren, müssen Sie die Firewallregeln in Ihren Nutzerclustern aktualisieren. 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. Der Nutzercluster muss mindestens Version 1.30 haben. Falls nicht, aktualisieren Sie die Knotenpools auf die gkeOnPremVersion in der Konfigurationsdatei des Nutzerclusters, bevor Sie mit der Migration fortfahren. Führen Sie zur Überprüfung der Versionen den folgenden Befehl aus:

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 migrieren, um Controlplane V2 zu verwenden, 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:

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

    autoRepair:
  enabled: false

  2. Aktualisieren Sie den Administratorcluster:

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

Ersetzen Sie Folgendes:

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

Nach Abschluss der Migration müssen Sie die automatische Reparatur im Administratorcluster wieder aktivieren.

Problem mit der Always-On-Secret-Verschlüsselung prüfen

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

Wenn die Always-On-Secrets-Verschlüsselung jemals im Nutzercluster aktiviert wurde, müssen Sie die Schritte unter Always-On-Secrets-Verschlüsselung deaktivieren und Secrets entschlüsseln ausführen, bevor Sie mit der Migration beginnen. 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 jemals 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

Führen Sie die folgenden Schritte aus, um die Always-On-Secret-Verschlüsselung zu deaktivieren und Secrets zu entschlüsseln:

  1. Fügen Sie in der Konfigurationsdatei des Nutzerclusters dem Abschnitt secretsEncryption das Feld disabled: true hinzu, um die Always-On-Verschlüsselung von Secrets zu deaktivieren:

    secretsEncryption:
    mode: GeneratedKey
    generatedKey:
        keyVersion: KEY_VERSION
        disabled: true

  2. 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

  3. 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

  4. Manifeste aller Secrets im Nutzercluster im YAML-Format abrufen:

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

  5. Damit alle Secrets in etcd als Nur-Text 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.

Auf Probleme mit falsch konfigurierten Webhooks für Arbeitslasten prüfen

Wenn Sie den Nutzercluster für die Verwendung von Controlplane V2 migrieren, prüfen Sie, ob ein Problem mit falsch konfigurierten Webhooks für Arbeitslasten vorliegt.

Wenn Sie Webhooks haben, die System-Pods im Namespace kube-system enthalten, fügen Sie namespaceSelector hinzu, um den Namespace kube-system herauszufiltern.

Beispiel: 

  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - kube-system

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 Konfiguration des integrierten F5 BIG-IP-Load Balancers 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.

  1. 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

  2. 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 mit dem folgenden Befehl, ob DataPlane V2 im Cluster aktiviert ist:

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 Spezifikation NetworkPolicy haben, wenden Sie sich an den Google-Support.

Wenn Ihr Cluster einen NetworkPolicy verwendet, entfernen Sie die Spezifikation vorübergehend aus dem Cluster:

  1. Prüfen Sie, ob auf Ihren Cluster nicht systembezogene NetworkPolicy angewendet werden:

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

  2. Wenn die Ausgabe des vorherigen Schritts nicht leer war, speichern Sie jede NetworkPolicy-Spezifikation in einer Datei, damit Sie die Spezifikation nach der Aktualisierung des Clusters wieder 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 des NetworkPolicy, den Sie speichern.
    • NETWORK_POLICY_NAMESPACE ist der Namespace des NetworkPolicy.

  3. Löschen Sie 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:

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

  2. So aktivieren Sie Dataplane V2:

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

  3. Wenn Sie in einem vorherigen Schritt NetworkPolicy-Spezifikationen entfernt haben, die nicht zum System gehören, wenden Sie sie nach Abschluss des Updates mit diesem Befehl wieder an:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f NETWORK_POLICY_NAME.yaml

Nachdem Sie diese Schritte ausgeführt haben, ist Dataplane V2 aktiviert. Als Nächstes bereiten Sie die Migration Ihres Clusters auf den empfohlenen Load Balancer und die Controlplane V2 vor.

Migration des Load-Balancers 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 zur 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:

  1. Ändern Sie loadBalancer.kind in "ManualLB".
  2. Behalten Sie für das Feld loadBalancer.vips.ingressVIP denselben Wert bei.
  3. Wenn Sie zu Steuerungsebene V2 migrieren, ändern Sie den Wert des Felds loadBalancer.vips.controlPlaneVIP in die IP-Adresse, die Sie zugewiesen haben. Andernfalls können Sie den Wert beibehalten.
  4. 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, bereiten Sie die Migration zu MetalLB vor, indem Sie die Schritte in den folgenden Abschnitten ausführen.

Adresspools angeben

Der MetalLB-Controller weist IP-Adressen für Dienste zu. Wenn ein Anwendungsentwickler einen Dienst vom Typ LoadBalancer in einem Nutzercluster erstellt, weist der MetalLB-Controller automatisch eine IP-Adresse für den Dienst zu. Der MetalLB-Controller wählt eine IP-Adresse aus einem Adresspool aus, den Sie angeben.

Damit Ihr Nutzercluster genügend IP-Adressen hat, sollten Sie die maximale Anzahl der LoadBalancer-Dienste berücksichtigen, die wahrscheinlich aktiv sind. Geben Sie dann im Abschnitt loadBalancer.metalLB.addressPools der Konfigurationsdatei des Nutzerclusters genügend IP-Adressen an.

Adressen im Pool müssen im CIDR-Format oder im Bereichsformat vorliegen. Wenn Sie eine einzelne Adresse angeben möchten, verwenden Sie ein /32-CIDR. Beispiel:

addresses:
  -   "192.0.2.0/26"
  -   "192.0.2.64-192.0.2.72"
  -   "192.0.2.75/32"

Cluster-Konfigurationsdatei aktualisieren

Aktualisieren Sie die Clusterkonfigurationsdatei, um den Seesaw-Abschnitt zu entfernen und einen MetalLB-Abschnitt hinzuzufügen:

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

Das folgende Beispiel für eine Konfigurationsdatei für einen Nutzercluster zeigt diese Änderungen und die MetalLB-Konfiguration von:

  • Ein Adresspool für den MetalLB-Controller, aus dem Dienste vom Typ LoadBalancer ausgewählt werden können und die diesen zugewiesen werden. Die Ingress-VIP, die in diesem Beispiel 198.51.100.10 ist, 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 zu Controlplane V2 vorbereiten

Wenn für den Cluster Controlplane V2 nicht aktiviert ist:

  • Konfigurationsdatei des Nutzerclusters aktualisieren
  • Wenn der Cluster das manuelle Load-Balancing (loadBalancer.kind: "ManualLB") verwendet, 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:

  1. enableControlplaneV2 auf „true“ festlegen.
  2. Optional können Sie die Steuerungsebene für den Controlplane V2-Nutzercluster hochverfügbar machen. Wenn Sie von einem Nicht-HA- zu einem HA-Cluster wechseln möchten, ändern Sie masterNode.replicas von 1 in 3.
  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. Die Hostnamen sind erforderlich.
  4. Füllen Sie die Felder netmask und gateway im Abschnitt network.controlPlaneIPBlock aus.
  5. Wenn der Abschnitt network.hostConfig leer ist, füllen Sie ihn aus.
  6. 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 Knoten der Steuerungsebene befinden.
  7. Wenn der Nutzercluster manuelles Load-Balancing verwendet, setzen Sie loadBalancer.manualLB.controlPlaneNodePort und loadBalancer.manualLB.konnectivityServerNodePort auf 0. Sie sind nicht erforderlich, wenn Controlplane V2 aktiviert ist, müssen aber den Wert 0 haben.
  8. Wenn der Nutzercluster einen manuellen Load-Balancer verwendet, konfigurieren Sie ihn wie im nächsten Abschnitt beschrieben.

Zuordnungen im Load Balancer bei Bedarf anpassen

Wenn Ihr Nutzercluster bereits manuelles Load-Balancing verwendet, müssen Sie einige Zuordnungen auf Ihrem Load-Balancer konfigurieren. Wenn Sie von der integrierten F5 BIG-IP-Konfiguration zu einem manuellen Load Balancer 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 im Cluster konfiguriert sind, öffnet Kubernetes die NodePorts auf allen Clusterknoten, sodass jeder Knoten im Cluster den Datenebenen-Traffic verarbeiten kann.

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

Nutzercluster migrieren

Sehen Sie sich zuerst alle Änderungen an, die Sie an der Konfigurationsdatei des Nutzerclusters vorgenommen haben. Alle Load Balancer- und Controlplane V2-Einstellungen 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 zu Controlplane V2 werden durch das Update die folgenden Aktionen ausgeführt:

  1. Erstellt die Steuerungsebene eines neuen Clusters mit aktivierter ControlPlane V2.
  2. Beendet die Kubernetes-Steuerungsebene des Kubeception-Clusters.
  3. Erstellt einen etcd-Snapshot des Kubeception-Clusters.
  4. Schaltet die Knoten der Steuerungsebene des Nutzerclusters des Kubeception-Clusters aus. Bis zum Abschluss der Migration werden die Knoten nicht gelöscht, da so eine Fehlerbehebung durch Zurückgreifen auf diesen Kubeception-Cluster möglich ist.
  5. Stellt die Clusterdaten in der neuen Steuerungsebene mithilfe des in einem früheren Schritt erstellten etcd-Snapshots wieder her.
  6. Verbindet die Knoten des Knotenpools des Kubeception-Clusters mit der neuen Steuerungsebene, die mit dem neuen controlPlaneVIP erreichbar ist.
  7. Gleicht den wiederhergestellten Nutzercluster ab, damit er dem Endstatus des Clusters mit aktivierter ControlPlane V2 entspricht.

Wichtige Hinweise:

  • Während der Migration kommt es zu keinen Ausfallzeiten für Nutzercluster-Arbeitslasten.
  • Während der Migration kommt es zu Ausfallzeiten für die Steuerungsebene des Nutzerclusters. Die Steuerungsebene ist nicht verfügbar, wenn die Kubernetes-Steuerungsebene des Kubeception-Clusters beendet wird, bis die Knoten des Knotenpools des Kubeception-Clusters mit der neuen Steuerungsebene verbunden sind. 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 Steuerungsebene des Nutzerclusters 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:

  1. 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

  2. Wenn Sie zu Controlplane V2 migriert sind, aktualisieren Sie die Firewallregeln für Ihren Administratorcluster, um die Steuerungsebenenknoten des Kubeception-Nutzerclusters zu entfernen.

  3. Wenn Sie die Always-On-Secret-Verschlüsselung 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

  4. Wenn Sie die automatische Reparatur im Administratorcluster deaktiviert haben, aktivieren Sie das Feature 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 haben, 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