Auf dieser Seite wird beschrieben, wie Sie von einem Administratorcluster ohne Hochverfügbarkeit (HA) in Version 1.29 zu einem Administratorcluster mit Hochverfügbarkeit migrieren.
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 die Schritte im vorherigen Abschnitt ergeben haben, dass Sie den Verschlüsselungsschlüssel rotieren müssen, führen Sie die folgenden Schritte aus:
Erhöhen Sie den Wert von
keyVersion
in der Konfigurationsdatei für den Administratorcluster.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.
Verfahrensübersicht
Die Migration umfasst die folgenden Hauptschritte:
Bearbeiten Sie die Konfigurationsdatei des Administratorclusters.
Führen Sie
gkectl update admin
aus. Mit diesem Befehl wird Folgendes ausgeführt:Startet einen externen Cluster (Kind) und sorgt dafür, dass sich der aktuelle Administratorcluster ohne Hochverfügbarkeit in einem fehlerfreien Zustand befindet.
Erstellt eine neue Steuerungsebene für den Administratorcluster mit HA-Spezifikation und einem neuen VIP für die Steuerungsebene.
Deaktiviert die vorhandene Steuerungsebene des Administratorclusters.
Erstellt einen etcd-Snapshot des vorhandenen Administratorclusters.
Stellt die alten Administratorclusterdaten in der neuen HA-Steuerungsebene wieder her.
Gleicht den wiederhergestellten Administratorcluster ab, damit er dem Endstatus des HA-Administratorclusters entspricht.
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 Administratorclusters. Die Ausfallzeit beträgt laut unseren Tests weniger als 18 Minuten. Die tatsächliche Dauer hängt jedoch von der jeweiligen Infrastrukturumgebung ab.
Die Anforderungen für HA-Administratorcluster gelten weiterhin für die Migration von Nicht-HA- zu HA-Clustern. HA-Administratorcluster unterstützen beispielsweise Seesaw nicht. Wenn Sie also 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.
Nachdem die Migration erfolgreich abgeschlossen wurde, werden verbleibende Ressourcen wie die nicht HA-fähige Admin-Master-VM absichtlich für die Fehlerbehebung beibehalten.
Vor und nach der Migration
In der folgenden Tabelle sind die wichtigsten Unterschiede 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 |
Control-Plane-Pod-Replikate (kube-apiserver, kube-etcd usw.) | 1 | 3 |
Größe des Datenlaufwerks | 100GB * 1 | 25GB * 3 |
Pfad für Datenlaufwerke | 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 von kubeception-Nutzerclustern | 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
Außerdem müssen Sie einige andere Felder in der Konfigurationsdatei des Administratorclusters ändern, wie in den folgenden Abschnitten beschrieben.
IP-Adressen angeben
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"
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
Ersetzen Sie den Wert von loadBalancer.vips.controlPlaneVIP durch eine neue virtuelle IP-Adresse. Beispiel:
loadBalancer: vips: controlPlaneVIP: "172.16.20.59"
Zusätzliche Konfigurationsfelder aktualisieren
Setzen Sie adminMaster.replicas auf
3
:adminMaster: replicas: 3 cpus: 4 memoryMB: 8192
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 Datenspeicher unter dem Stammverzeichnis
anthos
generiert.Wenn loadBalancer.manualLB.controlPlaneNodePort einen Wert ungleich null hat, legen Sie ihn auf
0
fest.
Manuelle Load-Balancer-Konfiguration anpassen
Wenn Ihr Administratorcluster manuelles Load-Balancing verwendet, füllen Sie diesen Abschnitt aus. Überspringen Sie andernfalls diesen Abschnitt.
Konfigurieren Sie für jede der drei neuen IP-Adressen für Knoten der Steuerungsebene, die Sie im Abschnitt network.controlPlaneIPBlock angegeben haben, die folgende Zuordnung in Ihrem Load Balancer:
(oldControlPlaneVIP:443) -> (NEW_NODE_IP_ADDRESS:oldControlPlaneNodePort)
Diese Zuordnung sorgt dafür, dass die alte VIP der Steuerungsebene während der Migration funktioniert.
Aktualisieren Sie den Administratorcluster:
Prüfen Sie die Konfigurationsänderungen, die Sie vorgenommen haben, da die Felder unveränderlich sind. Wenn Sie bestätigt haben, dass die Änderungen korrekt sind, aktualisieren Sie den Cluster.
Migration starten:
gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG
Ersetzen Sie Folgendes:
ADMIN_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters.
ADMIN_CLUSTER_CONFIG: der Pfad Ihrer Administratorcluster-Konfigurationsdatei.
Der Befehl zeigt den Fortschritt der Migration an.
Geben Sie bei Aufforderung
Y
ein, um fortzufahren.Nach Abschluss der Migration wird die kubeconfig-Datei des Administratorclusters automatisch aktualisiert, um die neue VIP der Steuerungsebene zu verwenden. Die ältere VIP der Steuerungsebene funktioniert weiterhin und kann auch für den Zugriff auf den neuen HA-Administratorcluster verwendet werden.