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:

Die Velero-CLI v1.11.1 muss auf Ihrer lokalen Workstation ausgeführt werden; siehe Installieren der Velero-CLI.
Einen Speicheranbieter mit Speicherorten zum Speichern der Sicherungen; siehe Einrichten eines Speicheranbieters.
Ein Velero-Server, der auf den Clustern ausgeführt wird, die Sie sichern:
- Velero auf einem Arbeitslastcluster sichert dazugehörige Arbeitslasten und dynamische Speicher, wie unten beschrieben.
- Velero auf einem eigenständigen Verwaltungscluster sichert Arbeitslastclusterobjekte, wie unter Back Up and Restore Management and Workload Cluster Infrastructure beschrieben.

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:

Öffnen Sie die Download-Seite von Tanzu Kubernetes Grid und melden Sie sich mit Ihren Anmeldedaten für VMware Customer Connect an.
Klicken Sie unter Produkt-Downloads auf Zu den Downloads.
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-.
Verwenden Sie den Befehl gunzip oder das Extraktionstool Ihrer Wahl, um die Binärdatei zu entpacken:
```
gzip -d <RELEASE-TARBALL-NAME>.gz
```
Ä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.

Befolgen Sie die Schritte unter Installieren der Velero-CLI, um Velero v1.11.1 zu installieren.
Aktualisieren Sie die CRD-Definitionen mit der Binärdatei Velero v1.11.1.
```
velero install --crds-only --dry-run -o yaml | kubectl apply -f -
```

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

(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:

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

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:

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:

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:

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

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:

Generieren Sie die kubeconfig-Datei neu:

tanzu cluster kubeconfig get CLUSTER-NAME --namespace NAMESPACE

Verteilen Sie die Ausgabe des obigen Befehls an alle Benutzer, die die Cluster verwenden, um die alte kubeconfig-Datei zu ersetzen.
- Die kubeconfig-Dateien enthalten keine Identitäten oder Anmeldedaten und können sicher weitergegeben werden, wie in der Pinniped-Dokumentation unter Learn to use Pinniped for federated authentication to Kubernetes clusters beschrieben.

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:

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

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

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

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.

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>

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

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

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

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.

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.
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.
  - Die kubeconfig-Dateien enthalten keine Identitäten oder Anmeldedaten und können sicher weitergegeben werden, wie in der Pinniped-Dokumentation unter Learn to use Pinniped for federated authentication to Kubernetes clusters beschrieben.

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:

Bevor Sie TKG aus einer Sicherung wiederherstellen, führen Sie den Befehl drift-detector aus, um einen Bericht zu generieren.
Laden Sie TKG von der letzten Sicherung herunter und stellen Sie es wieder her.
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:

Rufen Sie den Arbeitslastcluster kubeconfig ab und legen Sie ihn als den kubectl-Kontext fest.

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

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