Nutzercluster zu Steuerungsebene 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 mithilfe von kubeception zu Steuerungsebene V2 migrieren.

1,29: Vorschau
1,28: Nicht verfügbar
1.16: Nicht verfügbar

Nutzercluster-Steuerungsebenen

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

Zu den Vorteilen der Steuerungsebene V2 gehören:

• Fehlerisolierung. Ein Administratorclusterfehler hat keine Auswirkungen auf Nutzercluster.

• Operative Trennung. Ein Administratorclusterupgrade führt nicht zu Ausfallzeiten für Nutzercluster.

• Trennung der Bereitstellung. Sie können die Administrator- und Nutzercluster in verschiedenen Domains oder geografischen Standorten platzieren. Beispielsweise kann sich ein Nutzercluster an einem Edge-Standort an einem anderen geografischen Standort als der Administratorcluster befinden.

Voraussetzungen

Zum Migrieren eines Nutzerclusters zu Steuerungsebene V2 muss der Nutzercluster die folgenden Anforderungen erfüllen:

• Der Nutzercluster muss mindestens Version 1.29 haben. 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 also im Cluster nicht aktiviert ist, können Sie es nicht zu Steuerungsebene 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 das Dokument zur Planung von IP-Adressen und prüfen Sie, 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 vorhandenen Nutzercluster-Konfigurationsdatei vor:

1. Setzen Sie enableControlplaneV2 auf „true“.

2. Aktivieren Sie optional die Steuerungsebene für den Nutzercluster der Steuerungsebene V2. 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(n) 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. Füllen Sie im Abschnitt network.controlPlaneIPBlock die Netzmaske und das Gateway aus.

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 die Knoten-IP-Adressen der Steuerungsebene für Traffic auf der Datenebene einbezogen werden:

   • (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 unbedingt alle Einstellungen.

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

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

   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.

Konfigurieren Sie auf die gleiche Weise den Load-Balancer für einen CPv2-Nutzercluster für jede der drei neuen IP-Adressen für Knoten der Steuerungsebene, die Sie im Abschnitt network.controlPlaneIPBlock angegeben haben:

• (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 Steuerungsebene 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: Pfad der Konfigurationsdatei des Nutzerclusters.