Sichern und Wiederherstellen der Verwaltungs- und Arbeitslastclusterinfrastruktur auf vSphere (Tech Preview)

In diesem Thema wird erläutert, wie Sie die Clusterinfrastruktur für Tanzu Kubernetes Grid (TKG) mit einem eigenständigen Verwaltungscluster auf vSphere sichern und wiederherstellen, indem Sie:

  • Velero zum Sichern und Wiederherstellen von Arbeitslastclusterobjekten auf dem eigenständigen Verwaltungscluster verwenden und
  • den eigenständigen Verwaltungscluster aus seinen Konfigurationsdateien neu erstellen
Hinweis

  • VMware bietet keine Unterstützung für die Verwendung von Velero zum Sichern eigenständiger TKG-Verwaltungscluster.
  • Wenn ein eigenständiger Verwaltungscluster nach der Bereitstellung neu konfiguriert wird, werden bei einer erneuten Erstellung wie hier beschrieben möglicherweise nicht alle zugehörigen Ressourcen wiederhergestellt.

Informationen zum Sichern und Wiederherstellen der Arbeitslasten und dynamischen Speichervolumes, die auf Tanzu Kubernetes Grid(TKG)-Arbeitslastclustern mit einem eigenständigen Verwaltungscluster gehostet werden, finden Sie unter Sichern und Wiederherstellen von Clusterarbeitslasten.

Informationen zum Sichern und Wiederherstellen von vSphere with Tanzu-Clustern, einschließlich Supervisor-Clustern und den von ihnen erstellten Arbeitslastclustern, finden Sie in der Dokumentation zu VMware vSphere 8.0 unter Sichern und Wiederherstellen von vSphere with Tanzu.

Vorsicht

  • Diese Funktion befindet sich im nicht unterstützten Tech Preview-Zustand. Weitere Informationen finden Sie unter TKG-Funktionsstatus.

Velero einrichten

Sie können Velero, ein Open Source Community-Standardtool, verwenden, um Infrastruktur und Arbeitslasten eigenständiger TKG-Verwaltungscluster zu sichern und wiederherzustellen.

Velero unterstützt eine Vielzahl von Speicheranbietern für das Speichern der Sicherungen. Velero unterstützt auch:

  • Vorher- und Nachher-Hooks für das Sichern und Wiederherstellen, um benutzerdefinierte Prozesse vor oder nach Sicherungs- und Wiederherstellungsereignissen auszuführen.
  • Ausschließen von Aspekten des Arbeitslast- oder Clusterstatus, die für die Sicherung/Wiederherstellung nicht geeignet sind.

Ein Tanzu Kubernetes Grid-Abonnement bietet Unterstützung für die von VMware getestete, kompatible Velero-Verteilung, die über die Download-Seite für Tanzu Kubernetes Grid verfügbar ist.

Zum Sichern und Wiederherstellen von TKG-Clustern benötigen Sie Folgendes:

Nach Erfüllung der oben genannten Voraussetzungen können Sie auch mithilfe von Velero Arbeitslasten zwischen Clustern migrieren. Anweisungen finden Sie unter Clustermigration und Ressourcenfilterung in der Velero-Dokumentation.

Installieren der Velero-CLI

Wenn Sie die Velero-CLI bereits mit einer früheren Version von TKG installiert haben, müssen Sie Velero auf v1.11.1 aktualisieren. Weitere Informationen finden Sie unter Upgrade von Velero unten.

Um Velero CLI v1.11.1 zu installieren, gehen Sie wie folgt vor:

  1. Öffnen Sie die Download-Seite von Tanzu Kubernetes Grid und melden Sie sich mit Ihren Anmeldedaten für VMware Customer Connect an.
  2. Klicken Sie unter Produkt-Downloads auf Zu den Downloads.
  3. Scrollen Sie zu den Velero-Einträgen und laden Sie die .gz-Datei der Velero-CLI für das Betriebssystem Ihrer Workstation herunter. Der Dateiname beginnt mit velero-linux-, velero-mac- oder velero-windows64-.
  4. Verwenden Sie den Befehl gunzip oder das Extraktionstool Ihrer Wahl, um die Binärdatei zu entpacken:

    gzip -d <RELEASE-TARBALL-NAME>.gz
    
  5. Ändern Sie den Namen der CLI-Binärdatei für Ihre Plattform in velero, achten Sie darauf, dass es sich um eine ausführbare Datei handelt, und fügen Sie sie zu Ihrem PATH hinzu.

    macOS und Linux
    1. Verschieben Sie die Binärdatei in den Ordner /usr/local/bin und benennen Sie sie in velero um.
    2. Machen Sie die Datei ausführbar:
    chmod +x /usr/local/bin/velero
    
    Windows
    1. Erstellen Sie einen neuen Ordner Program Files\velero und kopieren Sie die Binärdatei in diesen Ordner.
    2. Ändern Sie den Namen der Binärdatei in velero.exe.
    3. Klicken Sie mit der rechten Maustaste auf den Ordner velero, wählen Sie Eigenschaften (Properties) > Sicherheit (Security) aus und stellen Sie sicher, dass Ihr Benutzerkonto über die Berechtigung Vollständige Kontrolle (Full Control) verfügt.
    4. Verwenden Sie die Windows-Suche, um nach env zu suchen.
    5. Wählen Sie Systemumgebungsvariablen bearbeiten (Edit the system environment variables) aus und klicken Sie auf die Schaltfläche Umgebungsvariablen (Environment Variables).
    6. Wählen Sie die Zeile Path unter Systemvariablen (System variables) aus und klicken Sie auf Bearbeiten (Edit).
    7. Klicken Sie auf Neu (New), um eine neue Zeile hinzuzufügen, und geben Sie den Pfad zu der velero-Binärdatei ein.

Upgrade von Velero

Wenn Sie TKG von v2.3 auf v2.4 aktualisiert haben, müssen Sie Velero auf v1.11.1 aktualisieren.

Wichtig

Velero v1.10.x verwendet unterschiedliche CRDs, unterschiedliche Komponentenbenennung und Funktionen anders als v1.9.x. Wenn Sie Velero v1.9.x noch mit TKG 2.3 verwendet haben und ein Upgrade auf TKG 2.4 durchgeführt haben, müssen Sie Velero von v1.9.x auf v1.10.x aktualisieren, bevor Sie ein Upgrade auf v1.11.1 durchführen können. Für Anweisungen zum Aktualisieren von Velero von v1.9.x auf v1.10.x befolgen Sie das Verfahren unter Upgrade von Velero in der TKG 2.3-Dokumentation, bevor Sie Velero auf v1.11.1 aktualisieren.

Führen Sie die folgenden Schritte aus, um Velero von v1.10.x auf v1.11.1 zu aktualisieren.

  1. Befolgen Sie die Schritte unter Installieren der Velero-CLI, um Velero v1.11.1 zu installieren.
  2. Aktualisieren Sie die CRD-Definitionen mit der Binärdatei Velero v1.11.1.

    velero install --crds-only --dry-run -o yaml | kubectl apply -f -
    
  3. Aktualisieren Sie die Velero-Bereitstellungskonfiguration, um die neue Version von Velero und die Version des Velero-Plug-Ins für Ihre Infrastruktur zu verwenden.

    vSphere
    kubectl set image deployment/velero \
        velero=velero/velero:v1.11.1 \
        velero-plugin-for-vsphere=velero/velero-plugin-for-vsphere:v1.5.1 \
        --namespace velero
    
    AWS
    kubectl set image deployment/velero \
        velero=velero/velero:v1.11.1 \
        velero-plugin-for-aws=velero/velero-plugin-for-aws:v1.7.1 \
        --namespace velero
    
    Azure
    kubectl set image deployment/velero \
        velero=velero/velero:v1.11.1 \
        velero-plugin-for-microsoft-azure=velero/velero-plugin-for-microsoft-azure:v1.7.1 \
        --namespace velero
    
  4. (Optional) Wenn Sie das Daemon-Set node verwenden, aktualisieren Sie die Version des Knotenagents.

    kubectl set image daemonset/node-agent \
       node-agent=velero/velero:v1.11.1 \
       --namespace velero 
    

Weitere Informationen finden Sie unter Upgrade auf Velero 1.11 in der Velero-Dokumentation.

Einrichten eines Speicheranbieters

Um Tanzu Kubernetes Grid-Arbeitslastclusterinhalte zu sichern, benötigen Sie Speicherorte für:

  • Sicherungen des Clusterobjektspeichers für Kubernetes-Metadaten in Clustern
  • Volume-Snapshots für von Clustern verwendete Daten

Weitere Informationen finden Sie in der Velero-Dokumentation unter Sichern von Speicherorten und Volume-Snapshot-Speicherorten in der Velero-Dokumentation. Velero unterstützt eine Vielzahl von Speicheranbietern. Hierbei kann es sich um

  • einen Online-Cloudspeicheranbieter oder
  • um einen lokalen Objektspeicherdienst (z. B. MinIO) für Proxy- oder Air-Gap-Umgebungen handeln.

VMware empfiehlt, jedem Cluster einen eindeutigen Speicher-Bucket zuzuweisen.

So richten Sie MinIO ein:

  1. Führen Sie das Container-Image minio mit MinIO-Anmeldedaten und einem Speicherort aus, z. B.:

    $ docker run -d --name minio --rm -p 9000:9000 -e "MINIO_ACCESS_KEY=minio" -e "MINIO_SECRET_KEY=minio123" -e "MINIO_DEFAULT_BUCKETS=mgmt" gcr.io/velero-gcp/bitnami/minio:2021.6.17-debian-10-r7
    
  2. Speichern Sie die Anmeldedaten in einer lokalen Datei und übergeben Sie sie an die Option --secret-file von velero install, z. B.:

    [default]
    aws_access_key_id=minio
    aws_secret_access_key=minio123
    

Speicher für vSphere

Unter vSphere werden Sicherungen des Clusterobjektspeichers und von Volume-Snapshots an demselben Speicherort gespeichert. Dieser Speicherort muss ein S3-kompatibler externer Speicher auf Amazon Web Services (AWS) oder ein S3-Anbieter wie MinIO sein.

Informationen zum Einrichten von Speicher für Velero unter vSphere finden Sie unter Velero-Plug-In für vSphere in Vanilla Kubernetes Cluster für das v1.5.1-Plug-In.

Speicher für und auf AWS

Um Speicher für Velero unter AWS einzurichten, befolgen Sie die Verfahren im Repository für Velero-Plug-Ins für AWS:

  1. Erstellen Sie einen S3-Bucket.

  2. Legen Sie Berechtigungen für Velero fest.

Richten Sie nach Bedarf S3-Speicher für jedes Plug-In ein. Das Objektspeicher-Plug-In speichert Clusterobjektsicherungen und ruft sie ab, und der Volume-Snapshotter speichert Datenvolumes und ruft sie ab.

Speicher für und in Azure

Um Speicher für Velero unter Azure einzurichten, befolgen Sie die Verfahren im Repository für Velero-Plug-Ins für Azure:

  1. Erstellen eines Azure-Speicherkontos und eines Blob-Containers

  2. Abrufen der Ressourcengruppe, die Ihre VMs und Festplatten enthält

  3. Festlegen von Berechtigungen für Velero

Richten Sie nach Bedarf S3-Speicher für jedes Plug-In ein. Das Objektspeicher-Plug-In speichert Clusterobjektsicherungen und ruft sie ab, und der Volume-Snapshotter speichert Datenvolumes und ruft sie ab.

Bereitstellen des Velero-Servers im Verwaltungscluster

Um Arbeitslastclusterobjekte zu sichern, installieren Sie den Velero v1.11.1-Server im eigenständigen Verwaltungscluster und überprüfen Sie die Installationen.

Velero-Installationsoptionen

Um Velero zu installieren, führen Sie velero install mit den folgenden Optionen aus:

  • --provider $PROVIDER: Beispiel: aws
  • --plugins projects.registry.vmware.com/tkg/velero/velero-plugin-for-aws:v1.7.1_vmware.1
  • --bucket $BUCKET: Der Name Ihres S3-Buckets
  • --backup-location-config region=$REGION: Die AWS-Region, in der sich der Bucket befindet
  • --snapshot-location-config region=$REGION: Die AWS-Region, in der sich der Bucket befindet
  • (Optional) --kubeconfig zum Installieren des Velero-Servers in einem anderen Cluster als dem aktuellen Standardcluster.
  • (Optional) --secret-file ./VELERO-CREDS Eine Möglichkeit, Velero den Zugriff auf einen S3-Bucket zu ermöglichen, besteht darin, in dieser Option eine lokale VELERO-CREDS -Datei zu übergeben, die wie folgt aussieht:

    [default]
    aws_access_key_id=<AWS_ACCESS_KEY_ID>
    aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
    
  • Weitere Optionen finden Sie unter Installieren und Starten von Velero.

Durch die Ausführung des Befehls velero install wird ein Namespace mit der Bezeichnung velero im Cluster erstellt sowie eine Bereitstellung mit der Bezeichnung velero darin platziert.

Die folgenden Einstellungen sind erforderlich:

  • Verwaltungscluster-Plug-In: Das folgende Plug-In ist erforderlich. Die Option hält die Cluster an und erfasst die Ressourcen im Zusammenhang mit den zu sichernden Clustern.
    --plugins projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.2.1_vmware.1
    
    Hinweis

    Sie können mehrere Optionen durch Kommas getrennt angeben. Beispiel:

    --plugins projects.registry.vmware.com/tkg/velero/velero-plugin-for-aws:v1.7.1_vmware.1,projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.2.1_vmware.1
    
  • Kein Snapshot-Speicherort: Legen Sie zum Sichern der Clusterinfrastruktur nicht --snapshot-location-config fest

Überprüfen der Velero-Installation

Stellen Sie nach Abschluss des Befehls velero install sicher, dass Velero erfolgreich installiert wurde:

  1. Stellen Sie sicher, dass der Velero-Pod den Status Running aufweist:

    kubectl -n velero get pod
    NAME                      READY   STATUS    RESTARTS   AGE
    velero-78fdbcd446-v5cqr   1/1     Running   0          3h41m
    
  2. Bestätigen Sie, dass sich der Sicherungsspeicherort im Status Available befindet:

    velero backup-location get
    NAME      PROVIDER   BUCKET/PREFIX   PHASE       LAST VALIDATED                  ACCESS MODE   DEFAULT
    default   aws        mgmt            Available   2022-11-11 05:55:55 +0000 UTC   ReadWrite     true
    

Sichern von Arbeitslastclusterobjekten

Führen Sie zum Sichern aller Arbeitslastclusterobjekte, die von einem eigenständigen Verwaltungscluster verwaltet werden, Folgendes aus:

velero backup create my-backup --exclude-namespaces tkg-system --include-resources cluster.cluster.x-k8s.io --wait
Hinweis

  • --exclude-namespaces tkg-system schließt den Verwaltungscluster selbst aus.
  • --include-resources cluster.cluster.x-k8s.io enthält die Arbeitslastclusterobjekte

  • VMware empfiehlt, Arbeitslastcluster sofort nach strukturellen Änderungen, wie z. B. einer Vergrößerung oder Verkleinerung, zu sichern. Dadurch wird eine Nichtübereinstimmung zwischen Sicherungsobjekten und der physischen Infrastruktur vermieden, die dazu führen kann, dass der Wiederherstellungsvorgang fehlschlägt.

Planen von Sicherungen

Wenn Clusterobjekte nach der letzten Sicherung geändert werden, entspricht der Zustand des Systems nach einer Wiederherstellung nicht dem gewünschten aktuellen Zustand. Dieses Problem wird als Abweichung bezeichnet. Weitere Informationen zur Erkennung und Behebung einiger gängiger Arten von Abweichungen finden Sie im Abschnitt Handhabung von Abweichungen weiter unten.

Um die Abweichung zu minimieren, empfiehlt VMware die Verwendung von Velero zur Planung häufiger, regelmäßiger Sicherungen. So sichern Sie beispielsweise alle Arbeitslastcluster täglich und bewahren jede Sicherung für 14 Tage auf:

velero create schedule daily-bak --schedule="@every 24h"  --exclude-namespaces tkg-system --include-resources cluster.cluster.x-k8s.io --ttl 336h0m0s

Weitere Optionen für die Planung mit Velero finden Sie in der Velero-Dokumentation unter Planen einer Sicherung.

Erneutes Generieren von kubeconfig-Dateien nach der Wiederherstellung

Nachdem Sie mit Velero einen Arbeitslastcluster wiederhergestellt haben, müssen Sie die neue kubeconfig-Datei an alle Benutzer des Clusters verteilen:

  1. Generieren Sie die kubeconfig-Datei neu:

    tanzu cluster kubeconfig get CLUSTER-NAME --namespace NAMESPACE
    
  2. Verteilen Sie die Ausgabe des obigen Befehls an alle Benutzer, die die Cluster verwenden, um die alte kubeconfig-Datei zu ersetzen.

Wiederherstellung abschließen

Um einen eigenständigen Verwaltungscluster und die von ihm verwalteten Arbeitslastcluster-Objekte wiederherzustellen, erstellen Sie den Verwaltungscluster anhand seiner Konfigurationsdatei neu, stellen seine Arbeitslastcluster mithilfe von Velero wieder her und verteilen neue kubeconfig-Dateien an die Personen, die sie verwenden:

  1. Wenn Sie eine Abweichung zwischen der letzten Sicherung der Arbeitslastcluster-Objekte und ihrem aktuellen Zustand vermuten, verwenden Sie das Tool „Drift Detector“, um einen Bericht zur Behebung der Abweichung zu erstellen, wie unter Verwenden des Drift Detectors beschrieben.

  2. Stellen Sie sicher, dass alle Konfigurationsänderungen, die nach der ursprünglichen Bereitstellung am Verwaltungscluster vorgenommen wurden, in der Konfigurationsdatei oder in den Umgebungsvariablen berücksichtigt werden. Andernfalls kann der letzte Zustand nicht wiederhergestellt werden.

  3. Erstellen Sie den Verwaltungscluster aus der dazugehörigen Konfigurationsdatei mgmt-cluster-config.yaml neu, wie unter Bereitstellen von Verwaltungsclustern über eine Konfigurationsdatei beschrieben.

    • Wenn Sie den Verwaltungscluster oder die zugehörigen Arbeitslastcluster in mehreren Verfügbarkeitsbereichen auf vSphere bereitgestellt haben (siehe Beschreibung unter Ausführen von Clustern in mehreren Verfügbarkeitsbereichen), schließen Sie die Datei mit den Objektdefinitionen VSphereFailureDomain und VSphereDeploymentZone ein, z. B. durch Aufnahme von --az-file vsphere-zones.yaml in den Befehl tanzu mc create.
  4. Unmittelbar nach der Erstellung des Verwaltungsclusters sollte nur ein TKR vorhanden sein:

    tanzu kubernetes-release get
    NAME                       VERSION                  COMPATIBLE  ACTIVE  UPDATES AVAILABLE
    v1.27.5---vmware.2-tkg.1  v1.27.5+vmware.1-tkg.1  True        True
    
  5. Warten Sie einige Minuten, bis alle von den gesicherten Arbeitslastclustern verwendeten TKRs verfügbar sind:

    tanzu kubernetes-release get
    NAME                       VERSION                  COMPATIBLE  ACTIVE  UPDATES AVAILABLE
    v1.25.13---vmware.2-tkg.2  v1.25.13+vmware.2-tkg.2  True        True
    v1.26.8---vmware.1-tkg.1  v1.26.8+vmware.1-tkg.1  True        True
    v1.27.5---vmware.2-tkg.1   v1.27.5+vmware.1-tkg.1   True        True
    
  6. Installieren Sie Velero auf dem Verwaltungscluster gemäß den Anweisungen unter Bereitstellen des Velero-Servers in Clustern (siehe oben). Stellen Sie sicher, dass die Konfigurationseinstellungen für die Anmeldedaten und den Sicherungsspeicherort dieselben Werte aufweisen wie zum Zeitpunkt der Sicherung.

  7. Führen Sie nach der Installation von Velero velero backup get aus, bis die Sicherungen synchronisiert sind und der Befehl die gewünschte Sicherung auflistet.

    velero backup get
    NAME                 STATUS      ERRORS   WARNINGS   CREATED                         EXPIRES   STORAGE LOCATION   SELECTOR
    my-backup            Completed   0        0          2022-12-07 17:10:42 +0000 UTC   24d       default            <none>
    
  8. Führen Sie velero restore create aus, um die Ressourcen des Arbeitslastclusters wiederherzustellen. VMware empfiehlt die Verwendung der neuesten Sicherung:

    velero restore create my-restore --from-backup my-backup --wait
    

    Nach Abschluss der Wiederherstellung befinden sich die Cluster im Status createdStalled:

    tanzu cluster list
    NAME                NAMESPACE  STATUS          CONTROLPLANE  WORKERS  KUBERNETES         ROLES   PLAN  TKR
    tkg-vc-antrea       default    createdStalled  0/3           0/3      v1.27.5+vmware.1   <none>  prod  v1.27.5---vmware.2-tkg.1
    
  9. Patchen Sie die Clusterobjekte, um deren Eigenschaft paused auf false festzulegen. Dies ist erforderlich, da Clusterobjekte im Zustand paused auf dem neuen Verwaltungscluster neu erstellt werden. Damit soll verhindert werden, dass ihre Controller versuchen, den Abgleich durchzuführen:

    • Um den Betrieb eines Cluster nach seiner Wiederherstellung fortzusetzen, führen Sie Folgendes aus:

      kubectl -n my-namespace patch cluster CLUSTER-NAME --type merge -p '{"spec":{"paused":false}}'
      
    • Um den Betrieb aller Cluster in mehreren Namespaces fortzusetzen, führen Sie das folgende Skript aus:

      #!/bin/bash
      
      for ns in $(kubectl get ns -o custom-columns=":metadata.name" | grep -v "tkg-system");
      do
            clusters=$(kubectl -n $ns get cluster -o name)
            if [[ -n $clusters ]];then
                    kubectl -n $ns patch $clusters --type merge -p '{"spec":{"paused":false}}'
            fi
      done
      
  10. Stellen Sie sicher, dass sich alle Arbeitslastcluster im Status running befinden, z. B.:

    tanzu cluster list
    NAME                NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES         ROLES   PLAN  TKR
    tkg-vc-antrea       default    running  3/3           3/3      v1.27.5+vmware.1   <none>  prod  v1.27.5---vmware.2-tkg.1
    
  11. Führen Sie für jeden Arbeitslastcluster tanzu cluster get CLUSTER-NAME aus, um zu überprüfen, ob sich alle Komponenten im Zustand running befinden, z. B.:

    tanzu cluster get tkg-vc-antrea
      NAME           NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES        ROLES   TKR
      tkg-vc-antrea  default    running  3/3           3/3      v1.27.5+vmware.1 <none>  v1.27.5---vmware.2-tkg.1
    
    Details:
    
    NAME                                                          READY  SEVERITY  REASON  SINCE  MESSAGE
    /tkg-vc-antrea                                                True                     4h14m
    ├─ClusterInfrastructure - VSphereCluster/tkg-vc-antrea-s6kl5  True                     4h36m
    ├─ControlPlane - KubeadmControlPlane/tkg-vc-antrea-ch5hn      True                     4h14m
    │ ├─Machine/tkg-vc-antrea-ch5hn-8gfvt                         True                     4h14m
    │ ├─Machine/tkg-vc-antrea-ch5hn-vdcrp                         True                     4h23m
    │ └─Machine/tkg-vc-antrea-ch5hn-x7nmm                         True                     4h32m
    └─Workers
      ├─MachineDeployment/tkg-vc-antrea-md-0-8b8zn                True                     4h23m
      │ └─Machine/tkg-vc-antrea-md-0-8b8zn-798d5b8897-bnxn9       True                     4h24m
      ├─MachineDeployment/tkg-vc-antrea-md-1-m6dvh                True                     4h24m
      │ └─Machine/tkg-vc-antrea-md-1-m6dvh-79fb858b96-p9667       True                     4h28m
      └─MachineDeployment/tkg-vc-antrea-md-2-brm2m                True                     4h21m
        └─Machine/tkg-vc-antrea-md-2-brm2m-6478cffc5f-tq5cn       True                     4h23m
    

    Wenn alle Arbeitslastcluster ausgeführt werden, können Sie die Arbeitslastcluster mit der Tanzu CLI verwalten.

  12. Wenn Sie vor dem erneuten Erstellen des Verwaltungsclusters den Drift Detector ausgeführt haben, müssen Sie alle im Bericht des Drift Detectors markierten Objekte manuell beheben oder untersuchen, wie unter Standardisieren von Abweichungen beschrieben.

  13. Generieren und verteilen Sie neue kubeconfig-Dateien für den Verwaltungscluster und seine Arbeitslastcluster:

    1. Generieren Sie die kubeconfig-Datei des Verwaltungsclusters neu:

      tanzu management-cluster kubeconfig get
      
    2. Generieren Sie für jeden Arbeitslastcluster seine kubeconfig-Datei neu:

      tanzu cluster kubeconfig get CLUSTER-NAME --namespace NAMESPACE
      
    3. Verteilen Sie die Ausgabe des obigen Befehls an alle Benutzer, die die Cluster verwenden, um die alten kubeconfig-Dateien zu ersetzen.

Handhabung von Abweichungen

Eine Abweichung tritt auf, wenn sich Clusterobjekte seit der letzten Sicherung geändert haben und der Zustand des Systems nach einer Wiederherstellung nicht mehr dem gewünschten, letzten Zustand entspricht.

Zur Minimierung der Abweichung empfiehlt VMware, häufige und regelmäßige Sicherungen zu planen.

Um Abweichungen zu erkennen und zu standardisieren, können Sie das Tool „Drift Detector“ verwenden, das in den folgenden Abschnitten beschrieben wird.

Verwenden des Drift Detectors

Drift Detector ist ein Befehlszeilen-Tool, das:

  • den Inhalt einer TKG-Sicherung mit dem aktuellen Zustand der TKG-Cluster-Objektinfrastruktur vergleicht und
  • einen Bericht erstellt, der potenzielle Probleme und Schritte zur Behebung der Abweichung auflistet.
Wichtig

Der Drift Detector befindet sich im nicht unterstützten Experimentellen Zustand. Abweichungen sind kompliziert, und der Drift Detector erkennt möglicherweise nicht alle Fälle von Abweichungen. Er sollte nur als Referenz und niemals als Ersatz für regelmäßige Sicherungen verwendet werden.

Informationen zum Installieren und Verwenden von Drift Detector finden Sie unter Drift Detector for Tanzu Kubernetes Grid Management Cluster auf der VMware KB-Website. Der Gesamtprozess ist folgender:

  1. Bevor Sie TKG aus einer Sicherung wiederherstellen, führen Sie den Befehl drift-detector aus, um einen Bericht zu generieren.

  2. Laden Sie TKG von der letzten Sicherung herunter und stellen Sie es wieder her.

  3. Beziehen Sie sich auf den Bericht des Drift Detectors und befolgen Sie die Anweisungen in Standardisieren von Abweichungen, um Standardisierungsmaßnahmen für den wiederhergestellten Zustand des TKG zu ergreifen.

Standardisieren von Abweichungen

Abweichungen können kompliziert sein, aber wenn Sie über einen Bericht des Drift Detectors verfügen oder anderweitig eine Abweichung im Zustand Ihres Clusterobjekts seit der letzten Sicherung feststellen, können Sie einige häufige Muster wie folgt beheben:

  • Veraltete Worker-Knoten:

    • Zusätzliche, nicht verwendete Knoten
    • Kann auftreten, wenn die Anzahl der Worker-Knoten nach der Sicherung herunterskaliert wurde
    • Risikominderung ist oft unnötig. Nach der Wiederherstellung löscht die Maschinenintegritätsprüfung die veralteten Maschinenobjekte, und es werden neue Knoten erstellt, um die gewünschte Anzahl der Maschinen zu erfüllen.
  • Ghost-Worker-Knoten-Infrastruktur:

    • Überflüssige, nicht verwaltete Knoteninfrastruktur
    • Kann auftreten, wenn die Anzahl der Worker-Knoten nach der Sicherung hochskaliert wurde
    • Risikominderung:

      1. Rufen Sie den Arbeitslastcluster kubeconfig ab und legen Sie ihn als den kubectl-Kontext fest.
      2. Vergleichen Sie die Ausgabe der folgenden Befehle: kubectl und tanzu:

        # Get the actual worker nodes of the workload cluster
        $ kubectl --context tkg-vc-antrea-admin@tkg-vc-antrea get node
        NAME                                        STATUS   ROLES           AGE    VERSION
        tkg-vc-antrea-md-0-p9vn5-645498f59f-42qh9   Ready    <none>          44m    v1.27.5+vmware.1
        tkg-vc-antrea-md-0-p9vn5-645498f59f-shrpt   Ready    <none>          114m   v1.27.5+vmware.1
        tkg-vc-antrea-wdsfx-2hkxp                   Ready    control-plane   116m   v1.27.5+vmware.1
        
        # Get the worker nodes managed by the TKG
        $ tanzu cluster get tkg-vc-antrea
          NAME           NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES        ROLES   TKR
          tkg-vc-antrea  default    running  1/1           1/1      v1.27.5+vmware.1  <none>  v1.27.5---vmware.2-tkg.1-zshippable
        
          Details:
        
          NAME                                                          READY  SEVERITY  REASON  SINCE  MESSAGE
          /tkg-vc-antrea                                                True                     13m
          ├─ClusterInfrastructure - VSphereCluster/tkg-vc-antrea-b7fr9  True                     13m
          ├─ControlPlane - KubeadmControlPlane/tkg-vc-antrea-wdsfx      True                     13m
          │ └─Machine/tkg-vc-antrea-wdsfx-2hkxp                         True                     13m
          └─Workers
            └─MachineDeployment/tkg-vc-antrea-md-0-p9vn5                True                     13m
              └─Machine/tkg-vc-antrea-md-0-p9vn5-645498f59f-shrpt       True                     13m
        
      3. Für jeden Worker-Knoten, der in kubectl aufgeführt ist, der über keine Workers > Machine-Auflistung aus tanzu cluster get verfügt:

        1. Skalieren Sie die Worker vertikal auf den erwarteten Wert hoch, z. B.:

          tanzu cluster scale ${cluster_name} --worker-machine-count 2
          
        2. Verwenden Sie die Cluster-kubeconfig, um den Ghost-Knoten zu entleeren, der seine Arbeitslasten auf von TKG verwaltete Knoten verschiebt:
          kubectl drain ${node_name} --delete-emptydir-data --ignore-daemonsets
          
        3. Entfernen Sie den Ghost-Knoten aus dem Cluster:

          kubectl delete node ${node_name}
          
        4. Melden Sie sich bei vSphere oder einer anderen Infrastruktur an und entfernen Sie die VM manuell.

  • Veraltete Knoten und Ghost-Infrastruktur auf Steuerungsebene

    • Nicht verwendete Knoten und überflüssige Knoteninfrastruktur für die Steuerungsebene
    • Kann auftreten, wenn der Steuerungsebenenknoten nach der Sicherung ersetzt wurde
    • Risikominderung:

      1. Rufen Sie den Arbeitslastcluster kubeconfig ab und legen Sie ihn als den kubectl-Kontext fest.
      2. Vergleichen Sie die Ausgabe der folgenden Befehle: kubectl und tanzu:

        # Get the actual control plane nodes of the workload cluster
        $ kubectl --context wc-admin@wc get node
        NAME                             STATUS   ROLES           AGE    VERSION
        wc-2cjn4-4xbf8                   Ready    control-plane   107s   v1.27.5+vmware.1
        wc-2cjn4-4zljs                   Ready    control-plane   26h    v1.27.5+vmware.1
        wc-2cjn4-59v95                   Ready    control-plane   26h    v1.27.5+vmware.1
        wc-2cjn4-ncgxb                   Ready    control-plane   25h    v1.27.5+vmware.1
        wc-md-0-nl928-5df8b9bfbd-nww2w   Ready    <none>          26h    v1.27.5+vmware.1
        wc-md-1-j4m55-589cfcd9d6-jxmvc   Ready    <none>          26h    v1.27.5+vmware.1
        wc-md-2-sd4ww-7b7db5dcbb-crwdv   Ready    <none>          26h    v1.27.5+vmware.1
        
        # Get the control plane nodes managed by the TKG
        $ tanzu cluster get wc
        NAME  NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES        ROLES   TKR
        wc    default    updating 4/3           3/3      v1.27.5+vmware.1 <none>  v1.27.5---vmware.2-tkg.1-zshippable
        
        Details:
        
        NAME                                               READY  SEVERITY  REASON  SINCE  MESSAGE
        /wc                                                True                     24m
        ├─ClusterInfrastructure - VSphereCluster/wc-9nq7v  True                     26m
        ├─ControlPlane - KubeadmControlPlane/wc-2cjn4      True                     24m
        │ ├─Machine/wc-2cjn4-4xbf8                         True                     24m
        │ ├─Machine/wc-2cjn4-4zljs                         True                     26m
        │ └─Machine/wc-2cjn4-59v95                         True                     26m
        └─Workers
          ├─MachineDeployment/wc-md-0-nl928                True                     26m
          │ └─Machine/wc-md-0-nl928-5df8b9bfbd-nww2w       True                     26m
          ├─MachineDeployment/wc-md-1-j4m55                True                     26m
          │ └─Machine/wc-md-1-j4m55-589cfcd9d6-jxmvc       True                     26m
          └─MachineDeployment/wc-md-2-sd4ww                True                     26m
            └─Machine/wc-md-2-sd4ww-7b7db5dcbb-crwdv       True                     26m
        
      3. Für jeden control-plane-Knoten, der von kubectl aufgeführt ist und nicht über eine ControlPlane > Machine-Auflistung aus tanzu cluster get verfügt:

        1. Löschen Sie den Knoten:

          kubectl delete node ${node_name}
          
        2. Melden Sie sich bei vSphere oder einer anderen Infrastruktur an und entfernen Sie die VM manuell.
check-circle-line exclamation-circle-line close-line
Scroll to top icon