Copia de seguridad y restauración de la infraestructura del clúster de carga de trabajo y de administración en vSphere (vista previa técnica)

En este tema se explica cómo realizar una copia de seguridad y restaurar la infraestructura del clúster para Tanzu Kubernetes Grid (TKG) con un clúster de administración independiente en vSphere:

Usar Velero para realizar copias de seguridad y restaurar objetos del clúster de carga de trabajo en el clúster de administración independiente, y
Volver a crear el clúster de administración independiente desde sus archivos de configuración

Nota

VMware no admite el uso de Velero para realizar copias de seguridad de clústeres de administración independientes de TKG.

Si se vuelve a configurar un clúster de administración independiente después de implementarlo, es posible que al volver a crearlo como se describe aquí no se recuperen todos sus recursos.

Para realizar una copia de seguridad y restaurar las cargas de trabajo y los volúmenes de almacenamiento dinámicos alojados en clústeres de carga de trabajo de Tanzu Kubernetes Grid (TKG) con un clúster de administración independiente, consulte Copia de seguridad y restauración de cargas de trabajo de clúster.

Para realizar una copia de seguridad y restaurar clústeres de vSphere with Tanzu, incluidos los clústeres de supervisor y los clústeres de carga de trabajo que crean, consulte Realizar copias de seguridad y restaurar vSphere with Tanzu en la documentación de VMware vSphere 8.0.

Precaución

Esta función se encuentra en el estado de vista previa técnica no compatible; consulte Estados de funciones de TKG.

Configurar Velero

Puede utilizar Velero, una herramienta estándar de comunidad de código abierto, para realizar copias de seguridad y restaurar cargas de trabajo e infraestructuras de clúster de administración independiente de TKG.

Velero admite diversos proveedores de almacenamiento para almacenar sus copias de seguridad. Velero también admite:

Enlaces previos y posteriores para copias de seguridad y restauraciones para ejecutar procesos personalizados antes o después de los eventos de copia de seguridad y restauración.
Sin incluir aspectos del estado de la carga de trabajo o del clúster que no son adecuados para copias de seguridad o restauraciones.

Una suscripción de Tanzu Kubernetes Grid incluye compatibilidad con la distribución probada y compatible de Velero de VMware disponible en la página de descargas de Tanzu Kubernetes Grid.

Para realizar una copia de seguridad y restaurar clústeres de TKG, necesita:

La CLI de Velero v1.11.1 que se ejecuta en la estación de trabajo local; consulte Instalar la CLI de Velero.
Un proveedor de almacenamiento con ubicaciones en las que guardar las copias de seguridad; consulte Configurar un proveedor de almacenamiento.
Un servidor Velero que se ejecuta en los clústeres de los que está realizando una copia de seguridad:
- Velero en un clúster de carga de trabajo realiza una copia de seguridad de sus cargas de trabajo y almacenamiento dinámico, como se describe a continuación.
- Velero en un clúster de administración independiente realiza una copia de seguridad de los objetos del clúster de carga de trabajo, como se describe en Copia de seguridad y restauración de la infraestructura del clúster de carga de trabajo y de administración.

Después de completar los requisitos previos anteriores, también puede utilizar Velero para migrar cargas de trabajo entre clústeres. Para obtener instrucciones, consulte Migración de clústeres y Filtrado de recursos en la documentación de Velero.

Instalar la CLI de Velero

Si ya instaló la CLI de Velero con una versión anterior de TKG, debe actualizar Velero a la versión 1.11.1. Para obtener información, consulte Actualizar Velero a continuación.

Para instalar la CLI de Velero v1.11.1, haga lo siguiente:

Vaya a la página de descargas de Tanzu Kubernetes Grid e inicie sesión con sus credenciales de VMware Customer Connect.
En Descargas de productos, haga clic en Ir a descargas.
Desplácese hasta las entradas de Velero y descargue el archivo .gz de la CLI de Velero para el sistema operativo de la estación de trabajo. El nombre de archivo comienza con velero-linux-, velero-mac- o velero-windows64-.
Utilice el comando gunzip o la herramienta de extracción de su elección para descomprimir el archivo binario:
```
gzip -d <RELEASE-TARBALL-NAME>.gz
```
Cambie el nombre del archivo binario de la CLI de su plataforma a velero y asegúrese de que sea ejecutable y agréguelo a PATH.
macOS y Linux
1. Mueva el archivo binario a la carpeta /usr/local/bin y cámbiele el nombre a velero.
2. Haga que el archivo sea ejecutable:
```
chmod +x /usr/local/bin/velero
```
Windows
1. Cree una nueva carpeta Program Files\velero y copie el archivo binario en ella.
2. Cambie el nombre del archivo binario a velero.exe
3. Haga clic con el botón secundario en la carpeta velero, seleccione Propiedades (Properties) > Seguridad (Security) y asegúrese de que su cuenta de usuario tenga el permiso Control completo (Full Control).
4. Utilice Windows Search para buscar env.
5. Seleccione Editar las variables de entorno del sistema (Edit the system environment variables) y haga clic en el botón Variables de entorno (Environment Variables).
6. Seleccione la fila Path en Variables del sistema (System variables) y haga clic en Editar (Edit).
7. Haga clic en Nueva para agregar una nueva fila e introduzca la ruta en el archivo binario velero.

Actualizar Velero

Si actualizó TKG de la versión 2.3 a la 2.4, debe actualizar Velero a la versión 1.11.1.

Importante
Velero v1.10.x utiliza diferentes CRD, nombres de componentes diferentes y funciones de forma diferente a la versión 1.9.x. Si todavía utilizaba Velero v1.9.x con TKG 2.3 y actualizó a TKG 2.4, debe actualizar Velero de v1.9.x a v1.10.x antes de poder actualizar a v1.11.1. Para obtener instrucciones sobre cómo actualizar Velero de v1.9.x a v1.10.x, siga el procedimiento para Actualizar Velero en la documentación de TKG 2.3 antes de actualizar Velero a v1.11.1.

Para actualizar Velero de v1.10.x a v1.11.1, realice los siguientes pasos.

Siga el procedimiento descrito en Instalar la CLI de Velero para instalar Velero v1.11.1.
Actualice las definiciones de CRD con el archivo binario de Velero v1.11.1.
```
velero install --crds-only --dry-run -o yaml | kubectl apply -f -
```

Actualice la configuración de implementación de Velero para utilizar la nueva versión de Velero y la versión del complemento de Velero para la infraestructura.

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

(Opcional) Si utiliza el conjunto de daemon node, actualice la versión del agente del nodo.

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

Para obtener más información, consulte Actualizar a Velero 1.11 en la documentación de Velero.

Configurar un proveedor de almacenamiento

Para realizar una copia de seguridad del contenido del clúster de carga de trabajo de Tanzu Kubernetes Grid, necesita ubicaciones de almacenamiento para:

Copias de seguridad de almacenamiento de objetos de clúster para metadatos de Kubernetes en clústeres
Instantáneas de volumen para datos utilizados por clústeres

Consulte Ubicaciones de almacenamiento de copias de seguridad y Ubicaciones de instantáneas de volumen en la documentación de Velero. Velero admite diversos proveedores de almacenamiento, que pueden ser:

Un proveedor de almacenamiento en la nube conectado.
Un servicio de almacenamiento de objetos local, como MinIO, para entornos con proxy o aislados.

VMware recomienda dedicar un depósito de almacenamiento único a cada clúster.

Para configurar MinIO:

Ejecute la imagen de contenedor minio con las credenciales de MinIO y una ubicación de almacenamiento, por ejemplo:

$ 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

Guarde las credenciales en un archivo local para pasar a la opción --secret-file de velero install, por ejemplo:
```
[default]
aws_access_key_id=minio
aws_secret_access_key=minio123
```

Almacenamiento para vSphere

En vSphere, las copias de seguridad de almacenamiento de objetos de clúster y las instantáneas de volumen se guardan en la misma ubicación de almacenamiento. Esta ubicación debe ser un almacenamiento externo compatible con S3 en Amazon Web Services (AWS) o un proveedor S3, como MinIO.

Para configurar el almacenamiento de Velero en vSphere, consulte Complemento de Velero para vSphere en Vanilla Kubernetes Cluster para el complemento v1.5.1.

Almacenamiento para y en AWS

Para configurar el almacenamiento para Velero on AWS, siga los procedimientos descritos en el repositorio de complementos de Velero para AWS:

Configure el almacenamiento de S3 según sea necesario para cada complemento. El complemento de almacén de objetos almacena y recupera copias de seguridad de objetos del clúster y la instantánea de volumen almacena y recupera volúmenes de datos.

Almacenamiento para y en Azure

Para configurar el almacenamiento de Velero en Azure, siga los procedimientos descritos en los complementos de Velero para el repositorio de Azure:

Implementar el servidor Velero en el clúster de administración

Para realizar copias de seguridad de los objetos del clúster de carga de trabajo, instale el servidor Velero v1.11.1 en el clúster de administración independiente y compruebe las instalaciones.

Opciones de instalación de Velero

Para instalar Velero, ejecute velero install con las siguientes opciones:

--provider $PROVIDER: Por ejemplo, aws
--plugins projects.registry.vmware.com/tkg/velero/velero-plugin-for-aws:v1.7.1_vmware.1
--bucket $BUCKET: El nombre del contenedor S3
--backup-location-config region=$REGION: La región de AWS en la que se encuentra el contenedor
--snapshot-location-config region=$REGION: La región de AWS en la que se encuentra el contenedor
(Opcional) --kubeconfig para instalar el servidor de Velero en un clúster que no sea el predeterminado actual.
(Opcional) --secret-file ./VELERO-CREDS una forma de dar acceso de Velero a un contenedor S3 es pasar a esta opción un archivo VELERO-CREDS local similar al siguiente:
```
[default]
aws_access_key_id=<AWS_ACCESS_KEY_ID>
aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
```
Para obtener más opciones, consulte Instalar e iniciar Velero.

La ejecución del comando velero install crea un espacio de nombres denominado velero en el clúster, y coloca una implementación denominada velero en él.

Se requieren los siguientes ajustes:

Complemento del clúster de administración (Management cluster plugin): Se requiere el siguiente complemento. Esta opción pausa los clústeres y recopila los recursos relacionados con los clústeres de los que se está realizando la copia de seguridad.
```
--plugins projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.2.1_vmware.1
```
Nota
Puede agregar varias opciones separadas por comas. Por ejemplo:
```
--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
```
Sin ubicación de instantánea (No snapshot location): Para realizar una copia de seguridad de la infraestructura del clúster, no establezca --snapshot-location-config

Comprobar la instalación de Velero

Una vez completado el comando velero install, compruebe que Velero se haya instalado correctamente:

Compruebe que el estado del pod de Velero es Running:

kubectl -n velero get pod
NAME                      READY   STATUS    RESTARTS   AGE
velero-78fdbcd446-v5cqr   1/1     Running   0          3h41m

Verifique que la ubicación de la copia de seguridad esté en la fase Available:

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

Copia de seguridad de objetos del clúster de carga de trabajo

Para realizar una copia de seguridad de todos los objetos del clúster de carga de trabajo administrados por un clúster de administración independiente, ejecute:

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

Nota

--exclude-namespaces tkg-system excluye el propio clúster de administración.

--include-resources cluster.cluster.x-k8s.io incluye los objetos del clúster de carga de trabajo

VMware recomienda realizar una copia de seguridad de los clústeres de carga de trabajo inmediatamente después de realizar cualquier cambio estructural, como un escalado vertical o descendente. Esto evita que los objetos de copia de seguridad y la infraestructura física no coincidan, lo que puede provocar errores en el proceso de restauración.

Programar copias de seguridad

Cuando se cambian los objetos del clúster después de la copia de seguridad más reciente, el estado del sistema después de una restauración no coincide con el estado deseado más reciente. Este problema se denomina "desfase". Consulte la sección Gestionar desfase a continuación para obtener información sobre cómo detectar y recuperarse de algunos tipos comunes de desfase.

Para minimizar las desviaciones, VMware recomienda utilizar Velero para programar copias de seguridad periódicas y frecuentes. Por ejemplo, para realizar una copia de seguridad diaria de todos los clústeres de carga de trabajo y conservar cada copia de seguridad durante 14 días:

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

Para obtener más opciones de instalación de Velero, consulte Programar copia de seguridad en la documentación de Velero.

Volver a generar archivos `kubeconfig` después de la restauración

Después de usar Velero para restaurar un clúster de carga de trabajo, debe distribuir su nuevo archivo kubeconfig a cualquiera que lo utilice:

Vuelva a generar el kubeconfig:

tanzu cluster kubeconfig get CLUSTER-NAME --namespace NAMESPACE

Distribuya el resultado del comando anterior a cualquiera que utilice los clústeres para reemplazar el archivo anterior kubeconfig.
- kubeconfiglos archivos no contienen identidades ni credenciales, y se pueden distribuir de forma segura como se describe en Aprend a usar Pinniped para la autenticación federada en clústeres de Kubernetes en la documentación de Pinniped.

Completar restauración

Para restaurar un clúster de administración independiente y los objetos del clúster de carga de trabajo que administra, vuelva a crear el clúster de administración desde su archivo de configuración, utilice Velero para restaurar sus clústeres de carga de trabajo y distribuya nuevos archivos kubeconfig a las personas que los utilizan:

Si sospecha que existe un desfase entre la copia de seguridad más reciente de los objetos del clúster de carga de trabajo y su estado de ejecución actual, utilice la herramienta Detector de desfase para generar un informe de corrección, como se describe en Utilizar detector de desfase.
Asegúrese de que los cambios de configuración que se realizaron en el clúster de administración después de su implementación se reflejen en su archivo de configuración o en las variables de entorno. De lo contrario, no se restaurará a su estado más reciente.
Vuelva a crear el clúster de administración desde su archivo de configuración,mgmt-cluster-config.yaml aquí, como se describe en Implementar clústeres de administración desde un archivo de configuración.
- Si implementó el clúster de administración o sus clústeres de carga de trabajo en varias zonas de disponibilidad en vSphere como se describe en Ejecución de clústeres en varias zonas de disponibilidad, incluya también el archivo con las definiciones de objetos VSphereFailureDomain yVSphereDeploymentZone, por ejemplo, incluyendo --az-file vsphere-zones.yaml en el comando tanzu mc create.

Inmediatamente después de crear el clúster de administración, debe haber una sola TKR:

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

Espere unos minutos hasta que estén disponibles todas las TKR que utilizan los clústeres de carga de trabajo con copia de seguridad:

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

Instale Velero en el clúster de administración siguiendo las instrucciones anteriores Implementar servidor Velero en clústeres. Asegúrese de que las credenciales y las opciones de configuración de ubicación de copia de seguridad tengan los mismos valores que cuando se realizó la copia de seguridad.

Después de instalar Velero, ejecute velero backup get hasta que se sincronicen las copias de seguridad y el comando muestre la copia de seguridad que desea utilizar:

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>

Ejecute velero restore create para restaurar los recursos del clúster de carga de trabajo. VMware recomienda utilizar la copia de seguridad más reciente:

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

Una vez completada la restauración, los clústeres tienen el estado 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

Aplique una revisión a los objetos del clúster para establecer su propiedad paused en false. Esto es necesario porque los objetos del clúster se vuelven a crear en un estado paused en el nuevo clúster de administración, para evitar que sus controladores intenten conciliar:
- Para anular la pausa de un clúster después de restaurarlo, ejecute:
```
kubectl -n my-namespace patch cluster CLUSTER-NAME --type merge -p '{"spec":{"paused":false}}'
```
- Para anular la pausa de todos los clústeres en varios espacios de nombres, ejecute el script:
```
#!/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
```

Compruebe que todos los clústeres de carga de trabajo estén en el estado running, por ejemplo:

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

Para cada clúster de carga de trabajo, ejecute tanzu cluster get CLUSTER-NAME para comprobar que todos los componentes estén en el estado running, por ejemplo:

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

Después de que todos los clústeres de carga de trabajo estén en ejecución, puede administrarlos con la CLI de Tanzu.

Si ejecutó Detector de desfase antes de volver a crear el clúster de administración, corrija manualmente o investigue los objetos marcados en el informe Detector de desfase, tal como se describe en Corregir desfase.
Vuelva a generar y distribuya nuevos archivos kubeconfig para el clúster de administración y sus clústeres de carga de trabajo:
1. Vuelva a generar el clúster de administración kubeconfig:
```
tanzu management-cluster kubeconfig get
```
2. Para cada clúster de carga de trabajo, vuelva a generar su kubeconfig:
```
tanzu cluster kubeconfig get CLUSTER-NAME --namespace NAMESPACE
```
3. Distribuya los resultados de los comandos anteriores a cualquier persona que utilice los clústeres de para reemplazar los archivos antiguos kubeconfig.
  - kubeconfiglos archivos no contienen identidades ni credenciales, y se pueden distribuir de forma segura como se describe en Aprend a usar Pinniped para la autenticación federada en clústeres de Kubernetes en la documentación de Pinniped.

Gestionar desfase

Se produce desfase cuando los objetos del clúster han cambiado desde su copia de seguridad más reciente, y el estado del sistema después de una restauración no coincide con el estado deseado más reciente.

Para minimizar la discrepancia, VMware recomienda programar copias de seguridad frecuentes y regulares.

Para ayudar a detectar y corregir la desviación, puede utilizar la herramienta Detector de desviación que se describe en las secciones siguientes.

Usar detector de desviaciones

Detector de desviación es una herramienta de línea de comandos que:

Compara el contenido de una copia de seguridad de TKG con el estado actual de la infraestructura de objetos de clúster de TKG, y
Genera un informe que enumera los posibles problemas y los pasos para corregir el desfase

Importante
El detector de desfase se encuentra en el estado experimental no compatible. La desviación es complicada, y es posible que el detector de desfase no detecte todas las instancias de desfase. Solo debe utilizarse como referencia y nunca como sustituto de las copias de seguridad normales.

Para obtener información sobre cómo instalar y utilizar el detector de desviaciones, consulte Detector de desfase para el clúster de administración Tanzu Kubernetes Grid en la página web de VMware KB. El proceso general es:

Antes de restaurar TKG desde una copia de seguridad, ejecute el comando drift-detector para generar un informe.
Descargue y restaure TKG desde la copia de seguridad más reciente.
En referencia al informe del detector de desfase, siga las instrucciones de Corregir desfase para realizar acciones de corrección en el estado restaurado de TKG.

Corregir desfase

Los casos de desfase pueden ser complicados, pero si tiene un Detector de desfase informe o detecte de otro modo alguna desviación en el estado del objeto del clúster desde la última copia de seguridad, puede corregir algunos patrones comunes de la siguiente manera:

Nodos de trabajo obsoletos:
- Nodos adicionales sin utilizar
- Puede ocurrir si el recuento de nodos de trabajo se redujo después de la copia de seguridad
- La mitigación a menudo no es necesaria. Después de la restauración, la comprobación de estado de la máquina elimina los objetos de máquina obsoletos y se crean nuevos nodos para cumplir con el número de máquinas deseado.

Infraestructura de nodo de trabajo fantasma:

Infraestructura superflua de nodo sin administrar
Puede ocurrir si el recuento de nodos de trabajo aumentó después de la copia de seguridad

Mitigación:

Obtenga el clúster de carga de trabajokubeconfig y establézcalo como el contexto kubectl.

Compare los resultados de los siguientes comandos kubectl y 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

Para cada nodo de trabajo enumerado por kubectl que no tiene una lista Workers > Machine de tanzu cluster get:
1. Escale verticalmente los trabajos al valor esperado, por ejemplo:
```
tanzu cluster scale ${cluster_name} --worker-machine-count 2
```
2. Utilice el clúster kubeconfig para drenar el nodo fantasma, que mueve sus cargas de trabajo a los nodos administrados por TKG:
```
kubectl drain ${node_name} --delete-emptydir-data --ignore-daemonsets
```
3. Elimine el nodo fantasma del clúster:
```
kubectl delete node ${node_name}
```
4. Inicie sesión en vSphere u otra infraestructura y elimine manualmente la máquina virtual.

Nodos obsoletos e infraestructura fantasma en el plano de control

Nodos sin utilizar e infraestructura de nodos superfluos para el plano de control
Puede ocurrir si el nodo del plano de control se reemplazó después de la copia de seguridad