Sauvegarder et restaurer l'infrastructure de cluster de charge de travail et de gestion sur vSphere (version d'évaluation technique)

Cette rubrique explique comment sauvegarder et restaurer l'infrastructure de cluster pour Tanzu Kubernetes Grid (TKG) avec un cluster de gestion autonome sur vSphere en procédant comme suit :

• Utilisation de Velero pour sauvegarder et restaurer des objets de cluster de charge de travail sur le cluster de gestion autonome, et
• Recréation du cluster de gestion autonome à partir de ses fichiers de configuration

Remarque

• VMware ne prend pas en charge l'utilisation de Velero pour sauvegarder des clusters de gestion autonomes TKG.
• Si un cluster de gestion autonome est reconfiguré après son déploiement, sa recréation comme décrit ici risque de ne pas récupérer toutes ses ressources.

Pour sauvegarder et restaurer les charges de travail et les volumes de stockage dynamiques hébergés sur des clusters de charge de travail Tanzu Kubernetes Grid (TKG) avec un cluster de gestion autonome, reportez-vous à la section Sauvegarder et restaurer des charges de travail de cluster.

Pour sauvegarder et restaurer des clusters vSphere with Tanzu, y compris les clusters superviseurs et les clusters de charge de travail qu'ils créent, reportez-vous à la section Sauvegarde et restauration de vSphere with Tanzu dans la documentation de VMware vSphere 8.0.

Attention :

• Cette fonctionnalité est dans l'état Version d'évaluation technique non pris en charge. Reportez-vous à la section États des fonctionnalités TKG.

• L'authentification de Pinniped sur les clusters de charge de travail ne fonctionne pas après la recréation de leur cluster de gestion.

Configurer Velero

Vous pouvez utiliser Velero, un outil standard de la communauté open source, pour sauvegarder et restaurer l'infrastructure et les charges de travail de clusters de gestion autonome TKG.

Velero prend en charge divers fournisseurs de stockage pour stocker ses sauvegardes. Velero prend également en charge les éléments suivants :

• Configurez des hooks antérieurs et postérieurs pour la sauvegarde et la restauration, afin d'exécuter des processus personnalisés avant ou après des événements de sauvegarde et de restauration.
• Exclusion des aspects de la charge de travail ou de l'état du cluster qui ne sont pas adaptés à la sauvegarde/restauration.

Un abonnement Tanzu Kubernetes Grid inclut la prise en charge de la distribution Velero testée et compatible de VMware disponible sur la page de téléchargements Tanzu Kubernetes Grid.

Pour sauvegarder et restaurer des clusters TKG, vous avez besoin des éléments suivants :

• Velero CLI v1.9.7 en cours d'exécution sur le poste de travail local ; reportez-vous à la section Installer Velero CLI.
• Un fournisseur de stockage, avec des emplacements pour enregistrer les sauvegardes. Reportez-vous à la section Configurer un fournisseur de stockage.
• Un serveur Velero s'exécutant sur les clusters que vous sauvegardez :
  • Velero sur un cluster de charge de travail sauvegarde ses charges de travail et son stockage dynamique, comme décrit ci-dessous.
  • Velero sur un cluster de gestion autonome sauvegarde les objets du cluster de charge de travail, comme décrit dans Sauvegarder et restaurer l'infrastructure du cluster de gestion et de charge de travail.

Une fois les conditions préalables remplies ci-dessus, vous pouvez également utiliser Velero pour migrer les charges de travail entre les clusters. Pour obtenir des instructions, reportez-vous aux sections Migration des clusters et Filtrage des ressources dans la documentation de Velero.

Installer Velero CLI

Attention :

Si vous avez déjà installé Velero CLI v1.8.1 ou une version antérieure, comme distribué avec des versions précédentes de TKG, vous devez effectuer une mise à niveau vers la version v1.9.7. Les anciennes versions de Velero ne fonctionnent pas avec les CRD utilisées dans la version v1.9 et les versions ultérieures.

Pour installer Velero CLI v1.9.7, procédez comme suit :

1. Accédez à la page de téléchargements de Tanzu Kubernetes Grid et connectez-vous avec vos informations d'identification VMware Customer Connect.
2. Sous Téléchargements de produits, cliquez sur Accéder aux téléchargements.
3. Faites défiler jusqu'aux entrées Velero et téléchargez le fichier Velero CLI .gz pour le système d'exploitation de votre poste de travail. Son nom de fichier commence par velero-linux-, velero-mac- ou velero-windows64-.

4. Utilisez la commande gunzip ou l'outil d'extraction de votre choix pour décompresser le fichier binaire :

   gzip -d <RELEASE-TARBALL-NAME>.gz
   

5. Renommez le fichier binaire de CLI de votre plate-forme en velero, assurez-vous qu'il est exécutable, puis ajoutez-le à la variable PATH.

   • plates-formes macOS et Linux :

     1. Déplacez le fichier binaire dans le dossier /usr/local/bin et renommez-le en velero.
     2. Rendez le fichier exécutable :

     chmod +x /usr/local/bin/velero
     

   • Plates-formes Windows :

     1. Créez un dossier Program Files\velero et copiez-y le fichier binaire.
     2. Renommez le fichier binaire en velero.exe.
     3. Cliquez avec le bouton droit sur le dossier velero, sélectionnez Propriétés (Properties) > Sécurité (Security) et assurez-vous que votre compte d'utilisateur dispose de l'autorisation Contrôle total (Full Control).
     4. Utilisez la recherche Windows pour rechercher env.
     5. Sélectionnez Modifier les variables d'environnement système (Edit the system environment variables) puis cliquez sur le bouton Variables d'environnement (Environment Variables).
     6. Sélectionnez la ligne Path sous Variables système (System variables), puis cliquez sur Modifier (Edit).
     7. Cliquez sur Nouveau (New) pour ajouter une nouvelle ligne et entrez le chemin d'accès au fichier binaire velero.

Configurer un fournisseur de stockage

Pour sauvegarder le contenu du cluster de charge de travail Tanzu Kubernetes Grid, vous avez besoin des emplacements de stockage pour les éléments suivants :

• Sauvegardes de stockage d'objets de cluster pour les métadonnées Kubernetes dans les clusters
• Snapshots de volume pour les données utilisées par les clusters

Reportez-vous à la section Backup Storage Locations and Volume Snapshot Locations dans la documentation de Velero. Velero prend en charge divers fournisseurs de stockage, qui peuvent être les suivants :

• Un fournisseur de stockage cloud en ligne.
• Un service de stockage d'objets sur site, tel que MinIO, pour les environnements mis en proxy ou isolés.

VMware recommande de dédier un compartiment de stockage unique à chaque cluster.

Pour configurer MinIO :

1. Exécutez l'image de conteneur minio avec les informations d'identification MinIO et un emplacement de stockage, par exemple :

   $ 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. Enregistrez les informations d'identification dans un fichier local à transmettre à l'option --secret-file de velero install, par exemple :

   [default]
   aws_access_key_id=minio
   aws_secret_access_key=minio123
   

Stockage pour vSphere

Sur vSphere, les sauvegardes de stockage d'objets de cluster et les snapshots de volume sont enregistrés dans le même emplacement de stockage. Cet emplacement doit être un stockage externe compatible S3 sur Amazon Web Services (AWS) ou un fournisseur S3, tel que MinIO.

Pour configurer le stockage de Velero sur vSphere, reportez-vous à la section Plug-in Velero pour vSphere dans le cluster Vanilla Kubernetes pour le plug-in v1.4.3.

Stockage pour et sur AWS

Pour configurer le stockage pour Velero sur AWS, suivez les procédures du référentiel Plug-ins Velero pour AWS :

1. Créer un compartiment S3.

2. Définir des autorisations pour Velero.

Configurez le stockage S3 si nécessaire pour chaque plug-in. Le plug-in de magasin d'objets stocke et récupère les sauvegardes d'objets de cluster, et l'outil de snapshot de volume stocke et récupère les volumes de données.

Stockage pour et sur Azure

Pour configurer le stockage pour Velero sur Azure, suivez les procédures du référentiel Plug-ins Velero pour Azure :

1. Créer un compte de stockage Azure et un conteneur blob

2. Obtenir le groupe de ressources contenant vos machines virtuelles et vos disques

3. Définir des autorisations pour Velero

Configurez le stockage S3 si nécessaire pour chaque plug-in. Le plug-in de magasin d'objets stocke et récupère les sauvegardes d'objets de cluster, et l'outil de snapshot de volume stocke et récupère les volumes de données.

Déployer le serveur Velero sur le cluster de gestion

Pour sauvegarder des objets de cluster de charge de travail, installez le serveur Velero v1.9.7 sur le cluster de gestion autonome et vérifiez les installations.

Options d'installation de Velero

Pour installer Velero, exécutez velero install avec les options suivantes :

• --provider $PROVIDER : Par exemple, aws
• --plugins projects.registry.vmware.com/tkg/velero/velero-plugin-for-aws:v1.5.5_vmware.1
• --bucket $BUCKET : Nom de votre compartiment S3
• --backup-location-config region=$REGION : Région AWS dans laquelle se trouve le compartiment
• --snapshot-location-config region=$REGION : Région AWS dans laquelle se trouve le compartiment
• (Facultatif) --kubeconfig, pour installer le serveur Velero sur un cluster autre que celui actuellement défini par défaut.

• (Facultatif) --secret-file ./VELERO-CREDS : une façon de donner à Velero l'accès à un compartiment S3 sur AWS consiste à transmettre à cette option un fichier VELERO-CREDS local qui ressemble à :

  [default]
  aws_access_key_id=<AWS_ACCESS_KEY_ID>
  aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
  

• Pour obtenir des options supplémentaires, reportez-vous à la section Install and start Velero.

L'exécution de cette commande velero install crée un espace de noms appelé velero sur le cluster, dans lequel un déploiement nommé velero est placé.

Les paramètres suivants sont requis :

• Plug-in de cluster de gestion : Le plug-in suivant est requis. L'option suspend les clusters et collecte les ressources associées aux clusters en cours de sauvegarde.

  --plugins projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.1.0_vmware.1
  

  Remarque

  Vous pouvez ajouter plusieurs options séparées par une virgule. Par exemple :

  --plugins projects.registry.vmware.com/tkg/velero/velero-plugin-for-aws:v1.5.5_vmware.1,projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.1.0_vmware.1
  

• Aucun emplacement de snapshot : pour la sauvegarde de l'infrastructure de cluster, ne définissez pas --snapshot-location-config

Vérifier l’installation de Velero

Une fois la commande velero install terminée, vérifiez que Velero a bien été installé :

1. Vérifiez que l'état de l'espace Velero est Running :

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

2. Vérifiez que l'emplacement de sauvegarde se trouve dans la phase 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
   

Sauvegarder les objets du cluster de charge de travail

Pour sauvegarder tous les objets de cluster de charge de travail gérés par un cluster de gestion autonome, exécutez :

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

Remarque

• --exclude-namespaces tkg-system exclut le cluster de gestion lui-même.

• --include-resources cluster.cluster.x-k8s.io inclut les objets du cluster de charge de travail

• VMware recommande de sauvegarder les clusters de charge de travail immédiatement après avoir apporté des modifications structurelles, telles que la montée ou la descente en puissance. Cela évite une non-correspondance entre les objets de sauvegarde et l'infrastructure physique qui peut faire échouer le processus de restauration.

Planification des sauvegardes

Lorsque des objets de cluster sont modifiés après la sauvegarde la plus récente, l'état du système après une restauration ne correspond pas à l'état le plus récent souhaité. Ce problème est appelé « dérive ». Reportez-vous à la section Gestion des dérives ci-dessous pour savoir comment récupérer à partir de certains types courants de dérive.

Pour atténuer la dérive, VMware recommande d'utiliser Velero pour planifier des sauvegardes régulières. Par exemple, pour sauvegarder tous les clusters de charge de travail quotidiennement et conserver chaque sauvegarde pendant 14 jours :

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

Pour plus d'options de planification de Velero, reportez-vous à la section Schedule a Backup dans la documentation de Velero.

Terminer la restauration

Pour restaurer un cluster de gestion autonome et les objets du cluster de charge de travail qu’il gère :

1. Recréez le cluster de gestion à partir de son fichier de configuration, mgmt-cluster-config.yaml ici, comme décrit dans Déployer des clusters de gestion à partir d'un fichier de configuration.

   Remarque

   Toutes les modifications de configuration appliquées au cluster de gestion après son déploiement doivent être reflétées dans le fichier de configuration ou les variables d'environnement, sinon elles ne seront pas restaurées.

2. Immédiatement après la création du cluster de gestion, il ne doit y avoir qu'une seule TKr :

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

3. Patientez quelques minutes jusqu'à ce que toutes les TKr utilisées par les clusters de charge de travail sauvegardés soient disponibles :

   tanzu kubernetes-release get
   NAME                       VERSION                  COMPATIBLE  ACTIVE  UPDATES AVAILABLE
   v1.23.17---vmware.2-tkg.2  v1.23.17+vmware.2-tkg.2  True        True
   v1.24.11---vmware.1-tkg.1  v1.24.11+vmware.1-tkg.1  True        True
   v1.25.7---vmware.1-tkg.1   v1.25.7+vmware.1-tkg.1 True        True
   

4. Installez Velero sur le cluster de gestion, en suivant les instructions Déployer le serveur Velero sur des clusters ci-dessus. Assurez-vous que les informations d'identification et les paramètres de configuration de l'emplacement de sauvegarde ont les mêmes valeurs que lors de la sauvegarde.

5. Après l'installation de Velero, exécutez velero backup get jusqu'à ce que les sauvegardes soient synchronisées et que la commande répertorie la sauvegarde que vous souhaitez utiliser :

   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. Exécutez velero restore create pour restaurer les ressources du cluster de charge de travail. VMware recommande d'utiliser la sauvegarde la plus récente :

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

   Une fois la restauration terminée, l'état des clusters est createdStalled :

   tanzu cluster list
   NAME                NAMESPACE  STATUS          CONTROLPLANE  WORKERS  KUBERNETES         ROLES   PLAN  TKR
   tkg-vc-antrea       default    createdStalled  0/3           0/3      v1.25.7+vmware.1   <none>  prod  v1.25.7---vmware.1-tkg.1
   

7. Corrigez les objets du cluster pour définir leur propriété paused sur false. Cela est nécessaire, car les objets du cluster sont recréés dans un état paused sur le nouveau cluster de gestion, afin d'empêcher leurs contrôleurs de tenter de concilier :

   • Pour annuler le couplage d'un cluster après sa restauration, exécutez :

     kubectl -n my-namespace patch cluster CLUSTER-NAME --type merge -p '{"spec":{"paused":false}}'
     

   • Pour annuler le couplage de tous les clusters dans plusieurs espaces de noms, exécutez le 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
     

8. Vérifiez que tous les clusters de charge de travail sont dans l'état running, par exemple :

   tanzu cluster list
   NAME                NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES         ROLES   PLAN  TKR
   tkg-vc-antrea       default    running  3/3           3/3      v1.25.7+vmware.1  <none>  prod  v1.25.7---vmware.1-tkg.1
   

9. Pour chaque cluster de charge de travail, exécutez tanzu cluster get CLUSTER-NAME pour vérifier que tous les composants sont dans l'état running, par exemple :

   tanzu cluster get tkg-vc-antrea
     NAME           NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES        ROLES   TKR
     tkg-vc-antrea  default    running  3/3           3/3      v1.25.7+vmware.1 <none>  v1.25.7---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
   

   Une fois que tous les clusters de charge de travail sont en cours d'exécution, vous pouvez gérer les clusters de charge de travail avec la CLI Tanzu.

Gestion des dérives

Les cas de dérive peuvent être compliqués, mais quelques modèles et atténuations courants incluent :

• Nœuds worker obsolètes :

  • Nœuds supplémentaires inutilisés.
  • Peut se produire si le nombre de nœuds worker a été réduit après la sauvegarde.
  • L'atténuation n'est souvent pas nécessaire. Après la restauration, le contrôle de santé de la machine supprime les objets de machine périmés et de nouveaux nœuds sont créés pour répondre au nombre de machines souhaité.

• Infrastructure de nœud worker fantôme :

  • Infrastructure de nœuds non gérés superflue
  • Peut se produire si le nombre de nœuds worker a été monté en charge après la sauvegarde

  • Atténuation :

    1. Obtenez le cluster de charge de travail kubeconfig et définissez-le sur le contexte kubectl.

    2. Comparez la sortie des commandes kubectl et tanzu suivantes :

       # 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.25.7+vmware.1
       tkg-vc-antrea-md-0-p9vn5-645498f59f-shrpt   Ready    <none>          114m   v1.25.7+vmware.1
       tkg-vc-antrea-wdsfx-2hkxp                   Ready    control-plane   116m   v1.25.7+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.25.7+vmware.1  <none>  v1.25.7---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. Pour chaque nœud worker répertorié par kubectl qui ne dispose pas d'une liste Workers > Machine de tanzu cluster get :

       1. Monter en puissance les travailleurs à la valeur attendue, par exemple :

          tanzu cluster scale ${cluster_name} --worker-machine-count 2
          

       2. Utilisez le cluster kubeconfig pour drainer le nœud fantôme, qui déplace ses charges de travail vers des nœuds gérés par TKG :

          kubectl drain ${node_name} --delete-emptydir-data --ignore-daemonsets
          

       3. Supprimez le nœud fantôme du cluster :

          kubectl delete node ${node_name}
          

       4. Connectez-vous à vSphere ou à une autre infrastructure et supprimez manuellement la machine virtuelle.

• Nœuds obsolètes et infrastructure fantôme sur le plan de contrôle

  • Nœuds inutilisés et infrastructure de nœuds superflue pour le plan de contrôle
  • Peut se produire si le nœud du plan de contrôle a été remplacé après la sauvegarde

  • Atténuation :

    1. Obtenez le cluster de charge de travail kubeconfig et définissez-le sur le contexte kubectl.

    2. Comparez la sortie des commandes kubectl et tanzu suivantes :

       # 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.25.7+vmware.1
       wc-2cjn4-4zljs                   Ready    control-plane   26h    v1.25.7+vmware.1
       wc-2cjn4-59v95                   Ready    control-plane   26h    v1.25.7+vmware.1
       wc-2cjn4-ncgxb                   Ready    control-plane   25h    v1.25.7+vmware.1
       wc-md-0-nl928-5df8b9bfbd-nww2w   Ready    <none>          26h    v1.25.7+vmware.1
       wc-md-1-j4m55-589cfcd9d6-jxmvc   Ready    <none>          26h    v1.25.7+vmware.1
       wc-md-2-sd4ww-7b7db5dcbb-crwdv   Ready    <none>          26h    v1.25.7+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.25.7+vmware.1 <none>  v1.25.7---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. Pour chaque nœud control-plane répertorié par kubectl qui ne dispose pas d'une liste ControlPlane > Machine provenant du cluster tanzu cluster get :

       1. Supprimez le nœud :

          kubectl delete node ${node_name}
          

       2. Connectez-vous à vSphere ou à une autre infrastructure et supprimez manuellement la machine virtuelle.