Nutzercluster zu Controlplane V2 migrieren

Vorschau

Diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Funktionen sind „wie besehen“ verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

In diesem Dokument wird gezeigt, wie Sie einen Nutzercluster der Version 1.29 oder höher mit kubeception zu Controlplane V2 migrieren.

1.29: Vorschau
1.28: Nicht verfügbar
1.16: Nicht verfügbar

Informationen zu Nutzercluster-Steuerungsebenen

Vor Version 1.13 von Google Distributed Cloud wurde die Steuerungsebene für einen Nutzercluster auf einem oder mehreren Knoten in einem Administratorcluster ausgeführt. Diese Art von Steuerungsebene wird Kubeception genannt. In Version 1.13 wurde Controlplane V2 für neue Nutzercluster eingeführt. Wenn Controlplane V2 aktiviert ist, wird die Steuerungsebene für den Nutzercluster im Nutzercluster selbst ausgeführt.

Zu den Vorteilen von Controlplane V2 gehören:

• Fehlerisolation. Ein Fehler des Administratorclusters hat keine Auswirkungen auf Nutzercluster.

• Operative Trennung. Ein Administratorclusterupgrade verursacht keine Ausfallzeiten für Nutzercluster.

• Bereitstellungstrennung. Sie können die Administrator- und Nutzercluster in verschiedenen Fehlerdomains oder geografischen Standorten platzieren. Ein Nutzercluster an einem Edge-Standort kann sich beispielsweise an einem anderen geografischen Standort befinden als der Administratorcluster.

Voraussetzungen

Damit ein Nutzercluster zu Controlplane V2 migriert werden kann, muss er die folgenden Anforderungen erfüllen:

• Der Nutzercluster muss mindestens Version 1.29 sein. Der Administratorcluster und die Knotenpools können eine oder zwei Nebenversionen niedriger als der Nutzercluster sein. Führen Sie bei Bedarf ein Upgrade des Clusters durch.

• Für den Nutzercluster muss Dataplane V2 aktiviert sein. Dieses Feld ist unveränderlich. Wenn Dataplane V2 im Cluster nicht aktiviert ist, können Sie es also nicht zu Controlplane V2 migrieren.

• Der Nutzercluster muss für die Verwendung des MetalLB oder eines manuellen Load-Balancers konfiguriert sein. Wenn der Nutzercluster den SeeSaw-Load-Balancer verwendet, können Sie ihn zu MetalLB migrieren.

• Prüfen Sie im Dokument zur Planung von IP-Adressen, ob genügend IP-Adressen für die Knoten der Steuerungsebene des Nutzerclusters verfügbar sind. Die Knoten der Steuerungsebene benötigen statische IP-Adressen und Sie benötigen eine zusätzliche IP-Adresse für eine neue virtuelle IP-Adresse (VIP) der Steuerungsebene.

Konfigurationsdatei des Nutzerclusters aktualisieren

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

1. Legen Sie enableControlplaneV2 auf „true“ fest.

2. Optional können Sie die Steuerungsebene für den Nutzercluster der Steuerungsebene V2 hochverfügbar machen. Wenn Sie von einem Cluster ohne Hochverfügbarkeit zu einem Cluster mit Hochverfügbarkeit wechseln möchten, ändern Sie masterNode.replicas von 1 in 3.

3. Fügen Sie dem Abschnitt network.controlPlaneIPBlock.ips die statische IP-Adresse (oder Adressen) für die Knoten der Steuerungsebene des Nutzerclusters hinzu. Entfernen Sie die IP-Adresse(n) für die Knoten der Steuerungsebene des kubeception-Nutzerclusters aus der IP-Blockdatei des Administratorclusters.

4. Geben Sie im Abschnitt network.controlPlaneIPBlock die Netzmaske und das Gateway ein.

5. Wenn der Abschnitt network.hostConfig leer ist, füllen Sie ihn aus.

6. Wenn der Nutzercluster manuelles Load-Balancing verwendet, konfigurieren Sie den Load-Balancer so, dass er die IP-Adressen der Knoten der Steuerungsebene für den Traffic der Datenebene enthält:

   • (ingressVIP:80) -> (CP_NODE_IP_ADDRESSES:ingressHTTPNodePort)
   • (ingressVIP:443) -> (CP_NODE_IP_ADDRESSES:ingressHTTPSNodePort)

7. Geben Sie im Feld loadBalancer.vips.controlPlaneVIP die neue IP-Adresse für die virtuelle IP-Adresse der Steuerungsebene ein.

8. Alle vorherigen Felder sind unveränderlich, außer wenn der Cluster für die Migration aktualisiert wird. Überprüfen Sie alle Einstellungen.

9. Führen Sie gkectl diagnose cluster aus und beheben Sie alle vom Befehl gefundenen Probleme.

   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.

   • CLUSTER_NAME: Der Name des Nutzerclusters.

Manuelle Load-Balancer-Konfiguration anpassen

Wenn Ihr Nutzercluster manuelles Load-Balancing verwendet, führen Sie den Schritt in diesem Abschnitt aus. Andernfalls können Sie diesen Abschnitt überspringen.

Wenn Sie den Load-Balancer für einen CPv2-Nutzercluster konfigurieren, konfigurieren Sie für jede der drei neuen IP-Adressen für Knoten der Steuerungsebene, die Sie im Abschnitt network.controlPlaneIPBlock angegeben haben, die Zuordnungen in Ihrem Load-Balancer:

• (IngressVIP:80) -> (NEW_NODE_IP_ADDRESS:IngressHTTPNodePort)
• (IngressVIP:443) -> (NEW_NODE_IP_ADDRESS:IngressHTTPNodePort)

Cluster aktualisieren

Führen Sie den folgenden Befehl aus, um den Cluster zu Controlplane V2 zu migrieren:

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

Ersetzen Sie Folgendes:

• ADMIN_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters

• USER_CLUSTER_CONFIG: der Pfad der Nutzercluster-Konfigurationsdatei.