Diese Seite wurde von der Cloud Translation API übersetzt.

Administratorcluster zur Hochverfügbarkeit migrieren

In diesem Dokument wird beschrieben, wie Sie von einem Administratorcluster ohne Hochverfügbarkeit zu einem Administratorcluster mit Hochverfügbarkeit migrieren.

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

Ein Hochverfügbarkeits-Administratorcluster hat drei Knoten der Steuerungsebene und keine Add-on-Knoten. Ein Administratorcluster ohne Hochverfügbarkeit hat einen Knoten der Steuerungsebene und zwei Add-on-Knoten.

Verfahrensübersicht

Dies sind die wichtigsten Schritte bei einer Migration:

Bearbeiten Sie die Konfigurationsdatei des Administratorclusters.
Führen Sie gkectl update admin aus. Mit diesem Befehl wird Folgendes ausgeführt:
- Richten Sie einen externen Cluster (Art) ein und prüfen Sie, ob der aktuelle Administratorcluster ohne Hochverfügbarkeit fehlerfrei ist.
- Erstellen Sie mit der Hochverfügbarkeitsspezifikation und einer neuen Steuerungsebene für die Steuerungsebene eine neue Steuerungsebene des Administratorclusters.
- Deaktivieren Sie die vorhandene Steuerungsebene des Administratorclusters.
- Erstellen Sie einen etcd-Snapshot des vorhandenen Administratorclusters.
- Stellen Sie die Daten des alten Administratorclusters in der neuen Steuerungsebene für Hochverfügbarkeit wieder her.
- Gleichen Sie den wiederhergestellten Administratorcluster ab, um den Endstatus des Hochverfügbarkeits-Administratorclusters zu erreichen.

Notes

Während der Migration gibt es keine Ausfallzeiten für die Arbeitslast des Nutzerclusters.
Während der Migration kommt es zu einer Ausfallzeit auf der Steuerungsebene des Administratorclusters. (Die Ausfallzeit beträgt laut unserem Test weniger als 18 Minuten, aber die tatsächliche Dauer hängt von der jeweiligen Infrastrukturumgebung ab.)
Für die Migration ohne Hochverfügbarkeit zur Hochverfügbarkeit gelten weiterhin die Anforderungen für Administratorcluster mit Hochverfügbarkeit. Wenn Sie also den Seesaw-Load-Balancer für einen Administratorcluster ohne Hochverfügbarkeit verwenden, müssen Sie zuerst zu MetalLB migrieren und dann zu einem Hochverfügbarkeits-Administratorcluster migrieren. Dies liegt daran, dass ein Hochverfügbarkeits-Administratorcluster Seesaw nicht unterstützt.
Nach erfolgreicher Migration bleiben Ressourcen übrig (z.B. die VM des Administrators ohne Hochverfügbarkeit), die wir absichtlich zur Fehlerwiederherstellung beibehalten haben. Sie können sie bei Bedarf manuell bereinigen.

Vor und nach der Migration

Dies sind die primären Unterschiede im Cluster vor und nach der Migration:

	Vor der Migration	Nach der Migration
Replikate für Knoten der Steuerungsebene	1	3
Add-on-Knoten	2	0
Pod-Replikate der Steuerungsebene (kube-apiserver, kube-etcd usw.)	1	3
Größe des Datenlaufwerks	100 GB × 1	25 GB × 3
Datenlaufwerkspfad	Durch vCenter.dataDisk in der Konfigurationsdatei des Administratorclusters festgelegt	Automatisch im Verzeichnis erstellt: `/anthos/[ADMIN_CLUSTER_NAME]/default/[MACHINE_NAME]-data.vmdk`
Load-Balancer für die virtuelle IP-Adresse der Steuerungsebene	Durch loadBalancer.kind in der Konfigurationsdatei des Administratorclusters festgelegt	`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 Nutzerclusters kubeception	DHCP oder statisch, je nach network.ipMode.type	DHCP oder statisch, je nach network.ipMode.type
Prüfpunktdatei	Standardmäßig aktiviert	Nicht verwendet

Konfigurationsdatei des Administratorclusters bearbeiten

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

Drei IP-Adressen für die Knoten der Steuerungsebene des Administratorclusters
Neue virtuelle IP-Adresse der Steuerungsebene für den Load-Balancer des Administratorclusters

Sie müssen auch einige andere Felder in der Konfigurationsdatei des Administratorclusters ändern.

IP-Adressen angeben

Füllen Sie in der Konfigurationsdatei des Administratorclusters 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 VIP. Beispiel:
```
loadBalancer:
 vips:
   controlPlaneVIP: "172.16.20.59"
```

Zusätzliche Konfigurationsfelder aktualisieren

Legen Sie adminMaster.replicas auf 3 fest:

adminMaster:
 replicas: 3
 cpus: 4
 memoryMB: 8192

Entfernen Sie das Feld vCenter.dataDisk. Dies liegt daran, dass bei einem Hochverfügbarkeits-Administratorcluster die Pfade für die drei von Knoten der Steuerungsebene verwendeten Datenlaufwerke automatisch unter dem Stammverzeichnis anthos im Datenspeicher generiert werden.
Wenn loadBalancer.manualLB.controlPlaneNodePort einen Wert ungleich null hat, legen Sie dafür 0 fest.

Manuelle Load-Balancer-Konfiguration anpassen

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

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

(alt ControlPlaneVIP:443) -> (NEW_NODE_IP_ADDRESS:old ControlPlaneNodePort)

So funktioniert die alte virtuelle IP-Adresse der Steuerungsebene während der Migration.

Administratorcluster aktualisieren

Starten Sie die Migration:
```
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 virtuelle IP-Adresse der Steuerungsebene zu verwenden. Die alte virtuelle IP-Adresse der Steuerungsebene funktioniert weiterhin und kann für den Zugriff auf den neuen Hochverfügbarkeits-Administratorcluster verwendet werden.

Verbleibende Ressourcen bei Bedarf manuell bereinigen

Während der Migration löscht gkectl die VM der Steuerungsebene des Administratorclusters nicht. Stattdessen wird die VM nur heruntergefahren, anstatt sie aus vSphere zu löschen. Wenn Sie die alte VM der Steuerungsebene nach einer erfolgreichen Migration löschen möchten, müssen Sie die Löschung manuell vornehmen.

So löschen Sie die alte VM der Steuerungsebene und die zugehörigen Ressourcen manuell:

Achten Sie darauf, dass die Administrator-Master-VM gke-admin-master-xxx ohne Hochverfügbarkeit bereits deaktiviert ist.
Löschen Sie die Administrator-Master-VM gke-admin-master-xxx ohne Hochverfügbarkeit aus vSphere.
Löschen Sie die VM-Vorlage gke-admin-master-xxx-tmpl des Administrators ohne Hochverfügbarkeit aus vSphere.
Löschen Sie das Nicht-HA-Administratordatenlaufwerk und die Administrator-Prüfpunktdatei.
Bereinigen Sie die in /home/ubuntu/admin-ha-migration/[ADMIN_CLUSTER_NAME]/ gespeicherten temporären Dateien.

Wenn die Verwendung von „cli“ bevorzugt wird, finden Sie die folgenden „govc“-Befehle:

  // Configure govc credentials
  export GOVC_INSECURE=1
  export GOVC_URL=VCENTER_URL
  export GOVC_DATACENTER=DATACENTER
  export GOVC_DATASTORE=DATASTORE
  export GOVC_USERNAME=USERNAME
  export GOVC_PASSWORD=PASSWORD

  // Configure admin master VM name (you can find the master VM name from the "[HA Migration]" logs)
  export ADMIN_MASTER_VM=ADMIN_MASTER_VM_NAME

  // Configure datadisk path (remove ".vmdk" suffix)
  export DATA_DISK_PATH=DATADISK_PATH_WITHOUT_VMDK

  // Check whether admin master is in "poweredOff" state:
  govc vm.info $ADMIN_MASTER_VM | grep Power

  // Delete admin master VM
  govc vm.destroy $ADMIN_MASTER_VM

  // Delete admin master VM template
  govc vm.destroy "$ADMIN_MASTER_VM"-tmpl

  // Delete data disk
  govc datastore.ls $DATA_DISK_PATH
  govc datastore.rm $DATA_DISK_PATH

  // Delete admin checkpoint file
  govc datastore.ls "$DATA_DISK_PATH"-checkpoint.yaml
  govc datastore.rm "$DATA_DISK_PATH"-checkpoint.yaml