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, die kubeception verwenden, zu Controlplane V2 migrieren.

  • Migrieren Sie die Load-Balancer-Konfiguration:

    • 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 inGoogle Cloud -Inhalten verweisen, finden Sie unter Häufig verwendete GKE-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 Ihre Produktionsumgebung zuletzt. So können Sie den Erfolg jeder Migration prüfen und sicherstellen, dass Ihre Arbeitslasten ordnungsgemäß ausgeführt werden, bevor Sie zur nächsten, kritischeren Umgebung übergehen.

Wir empfehlen, einen neuen Nutzercluster mit aktivierter 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 für Ihre Arbeitslasten bereit.

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

Voraussetzungen

Für diese Migration gilt:

  • 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, achten Sie darauf, dass Sie sich nicht auf Seesaw verlassen, um die Client-IP-Adresse beizubehalten, wie im nächsten Abschnitt beschrieben.

Beibehalten der Client-IP-Adresse durch Seesaw

Führen Sie den folgenden Befehl aus, um die externalTrafficPolicy zu prüfen:

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 jede Aktualisierung:

  • Wenn Sie von Seesaw zu MetalLB migrieren, planen Sie 15 Minuten für das Update ein, um einen Knotenpool für den MetalLB-Load-Balancer auszuwählen. Bei diesem Update wird nur der ausgewählte Knotenpool aktualisiert.
  • Multiplizieren Sie für alle anderen Aktualisierungen im Migrationsprozess 15 Minuten mit der Anzahl der Knoten im Knotenpool.

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

  1. Wenn der Nutzercluster die Always-On-Secret-Verschlüsselung verwendet, deaktivieren Sie das Feature 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. Bereiten Sie die Migration des Load Balancers und der Steuerungsebene vor:

    1. Wenn für den Administratorcluster die automatische Reparatur aktiviert ist, deaktivieren Sie sie. Führen Sie gkectl update admin aus. Dieses Update wird 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 dann gkectl update cluster aus. Bei diesem Update werden nur die Knoten im ausgewählten Knotenpool aktualisiert.

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

  5. Wenn Sie die Always-On-Secrets-Verschlüsselung deaktiviert haben, aktivieren Sie die Funktion nach der Migration 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. Dies hängt wiederum von Ihrer Konfiguration ab. Angenommen, Sie migrieren zu Dataplane V2, Controlplane V2 und MetalLB. Angenommen, der größte Knotenpool hat 10 Knoten und der Knotenpool, den MetalLB verwendet, hat 3 Knoten. Addieren Sie Folgendes, um eine Schätzung für die Migrationszeit zu berechnen:

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

Die Gesamtdauer der Migration beträgt etwa 345 Minuten, also 5 Stunden und 45 Minuten.

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 einem oder zwei Wartungsfenstern durchführen.

Ausfallzeit während der Migration einplanen

Berücksichtigen Sie bei der Planung Ihrer 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 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.
  • Arbeitslast-Ausfallzeit: Die virtuellen IP-Adressen (VIPs), die von Diensten vom Typ LoadBalancer verwendet werden, sind nicht verfügbar. Dies tritt nur während einer Migration von Seesaw zu MetalLB auf. Der MetalLB-Migrationsprozess stoppt die Netzwerkverbindungen zu allen VIPs im Nutzercluster für Kubernetes-Dienste vom Typ LoadBalancer für etwa zwei bis zehn Minuten. 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 gesetzt 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 fast nicht 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 den 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, 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. Wenn nicht, aktualisieren Sie die Knotenpools auf die 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 für die Verwendung von 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, führen Sie die folgenden Schritte aus:

  1. Legen Sie in der Konfigurationsdatei des Administratorclusters 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.

Auf Probleme mit der Always-On-Secret-Verschlüsselung prüfen

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

Wenn die Always-On-Secrets-Verschlüsselung schon einmal im Nutzercluster aktiviert war, 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 irgendwann 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 die Migration starten.

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 der Nutzercluster-Konfigurationsdatei

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

  5. Damit alle Secrets in etcd als 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 Steuerungsebene V2 beginnen. Nach Abschluss der Migration können Sie die Always-On-Secrets-Verschlüsselung wieder im Cluster aktivieren.

Auf Probleme mit falsch konfigurierten Arbeitslast-Webhooks prüfen

Wenn Sie den Nutzercluster zu Controlplane V2 migrieren, prüfen Sie, ob ein Problem mit falsch konfigurierten Arbeitslast-Webhooks 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 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.

  1. Wählen Sie im Abschnitt nodePools in der Konfigurationsdatei des Nutzerclusters 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:

Für die Migration zu Dataplane V2 haben Sie die folgenden Optionen:

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

  • Aktualisieren Sie den 1.30-Cluster.

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 haben, die NetworkPolicy-Spezifikation vorübergehend zu entfernen, wenden Sie sich an den Google-Support.

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

  1. Prüfen Sie, ob auf Ihren Cluster ein nicht systembezogenes NetworkPolicy angewendet wurde:

    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 dem Aktualisieren 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 der NetworkPolicy, die Sie speichern.
    • NETWORK_POLICY_NAMESPACE: der Namespace des NetworkPolicy.

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

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

  2. Aktualisieren Sie Ihren Cluster, um DataPlane V2 zu aktivieren:

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

  3. Wenn Sie in einem vorherigen Schritt nicht systembezogene NetworkPolicy-Spezifikationen entfernt haben, wenden Sie sie nach Abschluss des Updates mit diesem Befehl wieder an:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f NETWORK_POLICY_NAME.yaml

Sie haben Dataplane V2 aktiviert.

Inaktive Calico-DaemonSets entfernen

Nachdem Sie einen Administratorcluster oder Nutzercluster von Calico zu Dataplane V2 migriert haben, bleiben die DaemonSets calico-node und calico-route-daemon im Namespace kube-system inaktiv, um die Rollback-Funktion beizubehalten. Bevor Sie den Cluster skalieren oder aktualisieren, entfernen Sie die Annotation features.onprem.cluster.gke.io/dpv2-migration einmal pro migriertem Cluster, damit der Cluster-Controller die inaktiven Calico-DaemonSets dauerhaft löscht und verhindert, dass sie auf neuen Knoten initialisiert werden (siehe bekanntes Problem Zeitweilige Verbindungszeitüberschreitungen nach dem Upgrade oder Skalieren eines von Calico zu Dataplane V2 migrierten Clusters). Sie müssen diese Schritte nicht für Cluster ausführen, die mit aktiviertem Dataplane V2 erstellt wurden.

  1. Prüfen Sie, ob die Dataplane V2-Migration abgeschlossen ist und alle Knoten im Cluster das Label networking.gke.io/cni-type: cilium haben:

    kubectl --kubeconfig CLUSTER_KUBECONFIG get nodes -L networking.gke.io/cni-type

    Ersetzen Sie CLUSTER_KUBECONFIG durch den Pfad zur kubeconfig-Datei des Nutzer- oder Administratorclusters.

  2. Nachdem Sie bestätigt haben, dass Dataplane V2 auf allen Knoten ausgeführt wird und Sie kein Rollback zu Calico mehr durchführen müssen, entfernen Sie die Annotation features.onprem.cluster.gke.io/dpv2-migration aus der benutzerdefinierten Ressource OnPremUserCluster (und aus OnPremAdminCluster, wenn Ihr Administratorcluster während des Upgrades von Version 1.29 auf 1.30 von Calico migriert wurde):

    # For a user cluster:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG annotate onpremusercluster USER_CLUSTER_NAME \
    -n USER_CLUSTER_NAME-gke-onprem-mgmt \
    features.onprem.cluster.gke.io/dpv2-migration-

# For an admin cluster:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG annotate onpremadmincluster ADMIN_CLUSTER_NAME \
    -n kube-system \
    features.onprem.cluster.gke.io/dpv2-migration-

    Ersetzen Sie Folgendes:

    • ADMIN_CLUSTER_KUBECONFIG: Der Pfad zur kubeconfig-Datei des Administratorclusters.
    • USER_CLUSTER_NAME: Der Name des Nutzerclusters.
    • ADMIN_CLUSTER_NAME: der Name des Administratorclusters (kann mit kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get onpremadmincluster -n kube-system ermittelt werden).

  3. Prüfen Sie, ob der Controller die DaemonSets calico-node und calico-route-daemon gelöscht hat (beide geben NotFound zurück):

    kubectl --kubeconfig CLUSTER_KUBECONFIG -n kube-system get daemonset calico-node calico-route-daemon

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 integriertes F5 BIG-IP verwenden, führen Sie die Schritte in diesem Abschnitt aus, um die erforderlichen Änderungen an der Konfigurationsdatei des Nutzerclusters vorzunehmen. Andernfalls fahren Sie mit dem nächsten Abschnitt Migration zu Controlplane V2 vorbereiten fort.

F5 BIG-IP

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

  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 von Ihnen zugewiesene IP-Adresse. 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. Führen Sie dazu die Schritte in den folgenden Abschnitten aus.

Adresspools angeben

Der MetalLB-Controller weist Diensten IP-Adressen zu. Wenn ein Anwendungsentwickler einen Dienst vom Typ LoadBalancer in einem Nutzercluster erstellt, weist der MetalLB-Controller dem Dienst automatisch eine IP-Adresse zu. Der MetalLB-Controller wählt eine IP-Adresse aus einem von Ihnen angegebenen Adresspool aus.

Damit Ihr Nutzercluster genügend IP-Adressen hat, sollten Sie die maximale Anzahl von LoadBalancer-Diensten 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 CIDR vom Typ /32. Beispiel:

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

IP-Adressen ausschließen, die für andere Zwecke verwendet werden

Fügen Sie die folgenden IP-Adressen nicht in einen Adresspool ein:

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 von Ihnen zugewiesene IP-Adresse. Andernfalls können Sie den Wert beibehalten.
  5. Entfernen Sie den Abschnitt loadBalancer.seesaw.
  6. Fügen Sie einen loadBalancer.metalLB-Abschnitt hinzu.

Der folgende Teil einer 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 der diesen zugewiesen wird. Die virtuelle IP-Adresse für eingehenden Traffic, die in diesem Beispiel 198.51.100.10 ist, befindet sich in diesem Pool in der Bereichsformatnotation 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 Steuerungsebene V2 vorbereiten

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

  • Konfigurationsdatei des Nutzerclusters aktualisieren
  • Wenn der Cluster manuelles 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 Controlplane 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 Nutzercluster von Controlplane V2 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 statischen IP-Adressen für die Knoten der Steuerungsebene des Nutzerclusters im Abschnitt network.controlPlaneIPBlock.ips hinzu. Die IP-Adresse (oder Adressen) für die Knoten der Steuerungsebene muss sich im selben VLAN wie die Worker-Knoten befinden. Die Hostnamen sind erforderlich.
  4. Geben Sie im Abschnitt network.controlPlaneIPBlock die Werte für netmask und gateway ein.
  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 manuelles Load Balancing verwendet, konfigurieren Sie den Load Balancer 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 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 im Cluster konfiguriert sind, öffnet Kubernetes die NodePorts auf allen Clusterknoten, sodass jeder Knoten im Cluster Traffic auf der Datenebene 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 Standard-HTTP- und -HTTPS-Ports konfiguriert haben. 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

Prüfen Sie zuerst sorgfältig alle Änderungen, die Sie an der Konfigurationsdatei des Nutzerclusters vorgenommen haben. Alle Einstellungen für den Load Balancer und die Steuerungsebene V2 sind unveränderlich, außer wenn Sie den Cluster für die Migration aktualisieren.

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

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

Migration der Steuerungsebene V2

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

  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 die Migration abgeschlossen ist, werden die Knoten nicht gelöscht, da dies die Wiederherstellung nach einem Fehler durch ein Fallback auf diesen Kubeception-Cluster ermöglicht.
  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 über die neue controlPlaneVIP zugänglich ist.
  7. Gleicht den wiederhergestellten Nutzercluster ab, um den Endzustand des Clusters mit aktivierter Steuerungsebene V2 zu erreichen.

Wichtige Hinweise:

  • Während der Migration kommt es zu keinen Ausfallzeiten für Nutzercluster-Arbeitslasten.
  • Während der Migration kommt es zu einer gewissen Ausfallzeit für die Steuerungsebene des Nutzerclusters. Insbesondere ist die Steuerungsebene zwischen dem Beenden der Kubernetes-Steuerungsebene des Kubeception-Clusters und dem Abschluss der Verbindung der Knotenpoolknoten des Kubeception-Clusters mit der neuen Steuerungsebene nicht verfügbar. (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. Sie können die Knotenobjekte des Administratorclusters mit kubectl get nodes -o wide 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.
  • Am Ende der Migration durchlaufen die Worker-Knoten ein Rolling Update. Warten Sie, bis alle Knoten bereit sind, bevor Sie mit den Schritten nach der Migration im folgenden Abschnitt fortfahren.
  • Nach der Migration funktioniert die alte VIP-Adresse der Steuerungsebene zwar noch, ist aber instabil. Sie sind also nicht verlässlich. Aktualisieren Sie alle Abhängigkeiten von der alten VIP-Adresse so schnell wie möglich, um die neue VIP-Adresse zu verwenden.

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 in Ihrem Administratorcluster, um die Knoten der Steuerungsebene des Kubeception-Nutzerclusters zu entfernen.

  3. Wenn Sie die Always-on-Secret-Verschlüsselung deaktiviert haben, aktivieren Sie sie 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 die Funktion wieder.

    1. Legen Sie in der Konfigurationsdatei des Administratorclusters 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. Dies 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