Administratorcluster zu HA 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.

Auf dieser Seite erfahren Sie, wie Sie von einem Administratorcluster ohne Hochverfügbarkeit (HA) in Version 1.29 zu einem Administratorcluster mit Hochverfügbarkeit migrieren.

Hinweis: Wenn Ihre Cluster die Version 1.30 oder höher haben, empfehlen wir stattdessen die optimierte Vorgehensweise, die unter Clustermigration zu empfohlenen Funktionen planen beschrieben ist.

1.29: Vorabversion
1.28: Nicht verfügbar

Vor und nach der Migration hat der Administratorcluster drei Knoten:

• Ein Administratorcluster ohne Hochverfügbarkeit hat einen Steuerungsebenenknoten und zwei Add-on-Knoten.
• Ein HA-Administratorcluster hat drei Knoten der Steuerungsebene und keine Add-on-Knoten. Die Verfügbarkeit wird dadurch deutlich verbessert.

Migration vorbereiten

Wenn die Version Ihres Administratorclusters 1.29.0-1.29.600 oder 1.30.0-1.30.100 ist und die Verschlüsselung für Always-On-Secrets in der Version 1.14 oder niedriger aktiviert wurde, müssen Sie den Verschlüsselungsschlüssel rotieren, bevor Sie mit der Migration beginnen. Andernfalls kann der neue HA-Administratorcluster keine Secrets entschlüsseln.

So prüfen Sie, ob der Cluster möglicherweise einen alten Verschlüsselungsschlüssel verwendet:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret -n kube-system admin-master-component-options -o jsonpath='{.data.data}' | base64 -d | grep -oP '"GeneratedKeys":\[.*?\]'

Wenn die Ausgabe einen leeren Schlüssel enthält, wie im folgenden Beispiel, müssen Sie den Verschlüsselungsschlüssel rotieren.

"GeneratedKeys":[{"KeyVersion":"1","Key":""}]

Verschlüsselungsschlüssel bei Bedarf rotieren

Wenn Sie in den Schritten im vorherigen Abschnitt festgestellt haben, dass Sie den Verschlüsselungsschlüssel rotieren müssen, führen Sie die folgenden Schritte aus:

1. Erhöhen Sie keyVersion in der Konfigurationsdatei für den Administratorcluster.

2. Aktualisieren Sie den Administratorcluster:

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

   Dadurch wird ein neuer Schlüssel erstellt, der mit der neuen Versionsnummer übereinstimmt, jedes Secret wird neu verschlüsselt und alte Schlüssel werden sicher gelöscht. Alle nachfolgenden neuen Secrets werden mit dem neuen Verschlüsselungsschlüssel verschlüsselt.

Warnung: Wenn Sie die Migration gestartet haben, ohne den Verschlüsselungsschlüssel zu rotieren, wenden Sie sich an den Google-Support.

Verfahrensübersicht

Die Migration umfasst die folgenden Hauptschritte:

1. Bearbeiten Sie die Konfigurationsdatei des Administratorclusters.

2. Führen Sie gkectl update admin aus. Mit diesem Befehl wird Folgendes ausgeführt:

   • Hiermit wird ein externer Cluster (Kind) gestartet und dafür gesorgt, dass sich der aktuelle Administratorcluster ohne Hochverfügbarkeit in einem fehlerfreien Zustand befindet.

   • Erstellt eine neue Steuerungsebene für Administratorcluster mit HA-Spezifikation und einem neuen VIP der Steuerungsebene.

   • Deaktiviert die vorhandene Steuerungsebene des Administratorclusters.

   • Er erstellt einen etcd-Snapshot des vorhandenen Administratorclusters.

   • Stellt die alten Administratorclusterdaten in der neuen HA-Steuerungsebene wieder her.

   • Der wiederhergestellte Administratorcluster wird so abgeglichen, dass er den Endstatus des HA-Administratorclusters erfüllt.

Hinweise

• Während der Migration kommt es zu keinen Ausfallzeiten für die Arbeitslast des Nutzerclusters.

• Während der Migration kommt es zu einer kurzen Ausfallzeit der Steuerungsebene des Administratorclusters. Die Ausfallzeit beträgt laut unseren Tests weniger als 18 Minuten. Die tatsächliche Dauer hängt jedoch von den einzelnen Infrastrukturumgebungen ab.

• Die Anforderungen an HA-Administratorcluster gelten auch für die Migration von Nicht-HA- zu HA-Clustern. Seesaw wird beispielsweise nicht von HA-Administratorclustern unterstützt. Wenn Sie den Seesaw-Load Balancer für einen Administratorcluster ohne Hochverfügbarkeit verwenden, müssen Sie zuerst zu MetalLB migrieren, bevor Sie zu einem HA-Administratorcluster migrieren können.

• Nach Abschluss der Migration werden verbleibende Ressourcen wie die nicht HA-fähige VM des Administrator-Masters zur Fehlerwiederherstellung beibehalten.

Vor und nach der Migration

In der folgenden Tabelle sind die Hauptunterschiede im Cluster vor und nach der Migration aufgeführt:

	Vor der Migration	Nach der Migration
Replikate für Knoten der Steuerungsebene	1	3
Add-on-Knoten	2	0
Pod-Replikate der Kontrollebene (kube-apiserver, kube-etcd usw.)	1	3
Größe des Datenlaufwerks	100GB * 1	25GB * 3
Pfad zu Datenlaufwerken	Festgelegt durch vCenter.dataDisk in der Konfigurationsdatei des Administratorclusters	Automatisch generiert im Verzeichnis: /anthos/[ADMIN_CLUSTER_NAME]/default/[MACHINE_NAME]-data.vmdk
Load Balancer für die virtuelle IP-Adresse der Steuerungsebene	Festgelegt durch loadBalancer.kind in der Konfigurationsdatei des Administratorclusters	keepalived + haproxy
Zuweisung von IP-Adressen für Knoten der Steuerungsebene des Administratorclusters	DHCP oder statisch, je nach network.ipMode.type	3 statische IP-Adressen
Zuweisung von IP-Adressen für Knoten der Steuerungsebene des kubeception-Nutzerclusters	DHCP oder statisch, je nach network.ipMode.type	DHCP oder statisch, je nach network.ipMode.type
Checkpoint-Datei	Standardmäßig aktiviert	Nicht verwendet

Konfigurationsdatei für den Administratorcluster bearbeiten

Sie müssen vier zusätzliche IP-Adressen angeben:

• Drei IP-Adressen für die Knoten der Steuerungsebene des Administratorclusters
• Eine neue VIP der Steuerungsebene für den Load Balancer des Administratorclusters

Sie müssen auch einige andere Felder in der Konfigurationsdatei des Administratorclusters ändern, wie in den folgenden Abschnitten beschrieben.

IP-Adressen angeben

1. Füllen Sie in der Konfigurationsdatei für den Administratorcluster den Abschnitt network.controlPlaneIPBlock aus. Beispiel:

   controlPlaneIPBlock:
     netmask: "255.255.255.0"
     gateway: "172.16.20.1"
     ips:
     - ip: "172.16.20.50"
       hostname: "admin-cp-node-1"
     - ip: "172.16.20.51"
       hostname: "admin-cp-node-2"
     - ip: "172.16.20.52"
       hostname: "admin-cp-node-3"
   

2. Füllen Sie den Abschnitt hostconfig aus. Wenn Ihr Administratorcluster statische IP-Adressen verwendet, ist dieser Abschnitt bereits ausgefüllt. Beispiel:

   hostConfig:
     dnsServers:
     - 203.0.113.1
     - 198.51.100.1
     ntpServers:
     - 216.239.35.12
   

3. Ersetzen Sie den Wert von loadBalancer.vips.controlPlaneVIP durch eine neue VIP. Beispiel:

   loadBalancer:
    vips:
      controlPlaneVIP: "172.16.20.59"
   

Zusätzliche Konfigurationsfelder aktualisieren

1. Legen Sie für adminMaster.replicas den Wert 3 fest:

   adminMaster:
    replicas: 3
    cpus: 4
    memoryMB: 8192
   

2. Entfernen Sie das Feld vCenter.dataDisk. Bei einem hochverfügbaren Administratorcluster werden die Pfade für die drei Datenlaufwerke, die von Knoten der Steuerungsebene verwendet werden, automatisch im Stammverzeichnis anthos im Datenspeicher generiert.

3. Wenn loadBalancer.manualLB.controlPlaneNodePort einen Wert ungleich null hat, setzen Sie ihn auf 0.

Manuelle Load Balancer-Konfiguration anpassen

Wenn in Ihrem Administratorcluster manuelles Load Balancing verwendet wird, füllen Sie diesen Abschnitt aus. Überspringen Sie andernfalls diesen Abschnitt.

Konfigurieren Sie für jede der drei neuen IP-Adressen der Knoten der Steuerungsebene, die Sie im Abschnitt network.controlPlaneIPBlock angegeben haben, die folgende Zuordnung in Ihrem Load Balancer:

(old controlPlaneVIP:443) -> (NEW_NODE_IP_ADDRESS:old controlPlaneNodePort)

Durch diese Zuordnung wird sichergestellt, dass die alte VIP der Steuerungsebene während der Migration funktioniert.

Aktualisieren Sie den Administratorcluster:

Überprüfen Sie die von Ihnen vorgenommenen Konfigurationsänderungen, da die Felder unveränderlich sind. Wenn Sie die Änderungen überprüft haben, aktualisieren Sie den Cluster.

1. So starten Sie die Migration:

   gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG
   

   Ersetzen Sie Folgendes:

   • ADMIN_CLUSTER_KUBECONFIG: Pfad der kubeconfig-Datei des Administratorclusters.

   • ADMIN_CLUSTER_CONFIG: der Pfad Ihrer Administratorcluster-Konfigurationsdatei.

2. Der Befehl zeigt den Fortschritt der Migration an.

   Geben Sie bei Aufforderung Y ein, um fortzufahren.

3. Nach Abschluss der Migration wird die kubeconfig-Datei des Administratorclusters automatisch so aktualisiert, dass die neue VIP der Steuerungsebene verwendet wird. Die ältere VIP der Steuerungsebene funktioniert weiter und kann auch zum Zugriff auf den neuen HA-Administratorcluster verwendet werden.