Administratorcluster zu Hochverfügbarkeit 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 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 einer Migration:

1. Bearbeiten Sie die Konfigurationsdatei des Administratorclusters.

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

   • Rufen Sie einen externen Cluster (Art) auf und prüfen Sie, ob der aktuelle Administratorcluster ohne Hochverfügbarkeit in einem fehlerfreien Zustand ist.

   • Erstellen Sie eine neue Steuerungsebene des Administratorclusters mit der Hochverfügbarkeitsspezifikation und einer neuen virtuellen IP-Adresse der Steuerungsebene.

   • Deaktivieren Sie die vorhandene Steuerungsebene des Administratorclusters.

   • Erstellen Sie einen etcd-Snapshot des vorhandenen Administratorclusters.

   • Stellen Sie die alten Administratorclusterdaten in der neuen Hochverfügbarkeits-Steuerungsebene wieder her.

   • Gleichen Sie den wiederhergestellten Administratorcluster mit dem Endzustand des Hochverfügbarkeits-Administratorclusters ab.

Notes

• Während der Migration gibt es keine Ausfallzeiten für Nutzerclusterarbeitslasten.

• Während der Migration kommt es zu einer Ausfallzeit für die Steuerungsebene des Administratorclusters. Laut unserem Test beträgt die Ausfallzeit weniger als 18 Minuten, die tatsächliche Dauer hängt jedoch von der jeweiligen Infrastrukturumgebung ab.

• Die Anforderungen für Administratorcluster mit hoher Verfügbarkeit gelten weiterhin für eine Migration ohne Hochverfügbarkeit zu Hochverfügbarkeit. Das heißt: Wenn Sie 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. Das liegt daran, dass ein Hochverfügbarkeits-Administratorcluster Seesaw nicht unterstützt.

• Nach der erfolgreichen Migration gibt es noch Ressourcen (z.B. die Admin-Master-VM ohne Hochverfügbarkeit), die wir absichtlich für die Wiederherstellung nach Fehlern beibehalten haben. Sie können sie bei Bedarf manuell bereinigen.

Vor und nach der Migration

Dies sind die Hauptunterschiede 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	100GB * 1	25GB * 3
Pfad der Datenlaufwerke	Von vCenter.dataDisk in der Konfigurationsdatei des Administratorclusters festgelegt	Automatisch generiert im Verzeichnis: /anthos/[ADMIN_CLUSTER_NAME]/default/[MACHINE_NAME]-data.vmdk
Load-Balancer für die virtuelle IP-Adresse der Steuerungsebene	Von 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 kubeception-Nutzercluster-Steuerungsebene	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
• Eine neue virtuelle IP-Adresse der Steuerungsebene für den Load-Balancer des Administratorclusters

Außerdem müssen Sie einige andere Felder in der Konfigurationsdatei des Administratorclusters ändern.

IP-Adressen angeben

1. 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"
   

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. Das liegt daran, dass für einen Hochverfügbarkeits-Administratorcluster die Pfade für die drei Datenlaufwerke, die von Knoten der Steuerungsebene verwendet werden, automatisch unter dem Stammverzeichnis anthos im Datenspeicher generiert werden.

3. Wenn loadBalancer.manualLB.controlPlaneNodePort einen Wert ungleich null hat, legen Sie für diesen Wert 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 für Knoten der Steuerungsebene, die Sie im Abschnitt network.controlPlaneIPBlock angegeben haben, diese Zuordnung in Ihrem Load-Balancer:

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

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

Administratorcluster aktualisieren

1. 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.

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 aktualisiert, um die neue virtuelle IP-Adresse der Steuerungsebene zu verwenden. Die alte virtuelle IP-Adresse der Steuerungsebene funktioniert weiterhin und kann auch 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 dies manuell tun.

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

1. Achten Sie darauf, dass die Administrator-Master-VM gke-admin-master-xxx ohne Hochverfügbarkeit bereits ausgeschaltet ist.
2. Löschen Sie die Administrator-Master-VM gke-admin-master-xxx ohne Hochverfügbarkeit aus vSphere.
3. Löschen Sie die Administrator-Master-VM-Vorlage gke-admin-master-xxx-tmpl ohne Hochverfügbarkeit aus vSphere.
4. Löschen Sie das Administratordatenlaufwerk ohne Hochverfügbarkeit und die Administrator-Prüfpunktdatei.
5. Bereinige die in /home/ubuntu/admin-ha-migration/[ADMIN_CLUSTER_NAME]/ gespeicherten temporären Dateien.

Die folgenden govc-Befehle sind möglich, wenn die Verwendung von cli bevorzugt wird:

  // 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