This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

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.

  • Pinniped-Authentifizierung bei Arbeitslastclustern funktioniert nicht, nachdem deren Verwaltungscluster neu erstellt wurde.

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

Vorsicht

Wenn Sie die mit Vorgängerversionen von TKG verteilte Velero-CLI v1.8.1 oder früher bereits installiert haben, müssen Sie ein Upgrade auf v1.9.5 durchführen. Ältere Velero-Versionen funktionieren nicht mit den in v1.9 und höher verwendeten CRDs.

Gehen Sie zum Installieren der Velero-CLI v1.9.5 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-Plattformen:

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

      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.

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.4.2-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.9.5-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.5.3_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.1.0_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.5.3_vmware.1,projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.1.0_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

Anmerkungen

  • --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 Wiederherstellung einiger allgemeiner Abweichungstypen finden Sie im Abschnitt Handhabung von Abweichungen weiter unten.

Um Abweichungen zu vermeiden, empfiehlt VMware die Verwendung von Velero, um regelmäßige Sicherungen zu planen. 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.

Wiederherstellung abschließen

So stellen Sie einen eigenständigen Verwaltungscluster und die von ihm verwalteten Arbeitslastclusterobjekte wieder her:

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

    Hinweis

    Alle Konfigurationsänderungen, die nach der Bereitstellung auf den Verwaltungscluster angewendet wurden, müssen in der Konfigurationsdatei oder den Umgebungsvariablen angezeigt werden. Andernfalls werden sie nicht wiederhergestellt.

  2. Unmittelbar nach der Erstellung des Verwaltungsclusters sollte nur ein TKR vorhanden sein:

    tanzu kubernetes-release get
NAME                       VERSION                  COMPATIBLE  ACTIVE  UPDATES AVAILABLE
v1.24.10---vmware.1-tkg.1  v1.24.10+vmware.1-tkg.1  True        True

  3. 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.22.17---vmware.2-tkg.2  v1.22.17+vmware.2-tkg.2  True        True
v1.23.16---vmware.1-tkg.1  v1.23.16+vmware.1-tkg.1  True        True
v1.24.10---vmware.1-tkg.1   v1.24.10+vmware.1-tkg.1 True        True

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

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

  6. 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.24.10+vmware.1   <none>  prod  v1.24.10---vmware.1-tkg.1

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

  8. 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.24.10+vmware.1  <none>  prod  v1.24.10---vmware.1-tkg.1

  9. 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.24.10+vmware.1 <none>  v1.24.10---vmware.1-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.

Handhabung von Abweichungen

Abweichungsfälle können kompliziert sein, aber einige gängige Muster und Risikominderungen umfassen:

  • 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.24.10+vmware.1
tkg-vc-antrea-md-0-p9vn5-645498f59f-shrpt   Ready    <none>          114m   v1.24.10+vmware.1
tkg-vc-antrea-wdsfx-2hkxp                   Ready    control-plane   116m   v1.24.10+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.24.10+vmware.1  <none>  v1.24.10---vmware.1-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.24.10+vmware.1
wc-2cjn4-4zljs                   Ready    control-plane   26h    v1.24.10+vmware.1
wc-2cjn4-59v95                   Ready    control-plane   26h    v1.24.10+vmware.1
wc-2cjn4-ncgxb                   Ready    control-plane   25h    v1.24.10+vmware.1
wc-md-0-nl928-5df8b9bfbd-nww2w   Ready    <none>          26h    v1.24.10+vmware.1
wc-md-1-j4m55-589cfcd9d6-jxmvc   Ready    <none>          26h    v1.24.10+vmware.1
wc-md-2-sd4ww-7b7db5dcbb-crwdv   Ready    <none>          26h    v1.24.10+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.24.10+vmware.1 <none>  v1.24.10---vmware.1-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