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

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:

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:

  1. Vaya a la página de descargas de Tanzu Kubernetes Grid e inicie sesión con sus credenciales de VMware Customer Connect.
  2. En Descargas de productos, haga clic en Ir a descargas.
  3. 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-.
  4. 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
    
  5. 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.

  1. Siga el procedimiento descrito en Instalar la CLI de Velero para instalar Velero v1.11.1.
  2. 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 -
    
  3. 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
    
  4. (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:

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

  1. Crear un contenedor S3.

  2. Establecer permisos para Velero.

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:

  1. Crear una cuenta de almacenamiento de Azure y un contenedor de blob

  2. Obtener el grupo de recursos que contiene las máquinas virtuales y los discos

  3. Establecer permisos para Velero

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.

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:

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

  1. Vuelva a generar el kubeconfig:

    tanzu cluster kubeconfig get CLUSTER-NAME --namespace NAMESPACE
    
  2. Distribuya el resultado del comando anterior a cualquiera que utilice los clústeres para reemplazar el archivo anterior kubeconfig.

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:

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

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

  3. 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.
  4. 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
    
  5. 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
    
  6. 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.

  7. 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>
    
  8. 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
    
  9. 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
      
  10. 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
    
  11. 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.

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

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

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:

  1. Antes de restaurar TKG desde una copia de seguridad, ejecute el comando drift-detector para generar un informe.

  2. Descargue y restaure TKG desde la copia de seguridad más reciente.

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

      1. Obtenga el clúster de carga de trabajokubeconfig y establézcalo como el contexto kubectl.
      2. 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
        
      3. 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
    • Mitigación:

      1. Obtenga el clúster de carga de trabajokubeconfig y establézcalo como el contexto kubectl.
      2. Compare los resultados de los siguientes comandos kubectl y 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. Para cada nodo control-plane enumerado por kubectl que no tiene una lista ControlPlane > Machine de tanzu cluster get:

        1. Elimine el nodo:

          kubectl delete node ${node_name}
          
        2. Inicie sesión en vSphere u otra infraestructura y elimine manualmente la máquina virtual.
check-circle-line exclamation-circle-line close-line
Scroll to top icon