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

 

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 :

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 :

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.9.x 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.10.3. Les anciennes versions de Velero ne fonctionnent pas avec les CRD utilisées dans la version v1.10 et les versions ultérieures. Pour plus d'informations, reportez-vous à la section Mettre à niveau Velero ci-dessous.

Pour installer Velero CLI v1.10.3, 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.

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

Mettre à niveau Velero

Velero v1.10.3 utilise des CRD différentes vers la version v1.9.x. En outre, Velero v1.10 a adopté Kopia avec Restic comme chargeur, ce qui a conduit à plusieurs modifications dans l'attribution de nom des composants et des commandes, et dans le mode de fonctionnement de Velero. Pour plus d'informations sur les modifications importantes entre la version v1.9.x et la version v1.10, reportez-vous à la section Modifications importantes dans le journal des modifications de Velero v1.10. Si vous avez installé Velero v1.9.x avec une version précédente de TKG, vous devez mettre à niveau Velero.

  1. Suivez la procédure décrite dans la section Installer Velero CLI pour installer Velero v1.10.3.

  2. Mettez à jour les définitions CRD avec le fichier binaire Velero v1.10.

    velero install --crds-only --dry-run -o yaml | kubectl apply -f -

  3. Mettez à jour la configuration du déploiement et de l'ensemble de démons Velero pour qu'elle corresponde au changement de nom des composants qui s'est produit dans Velero v1.10.

    Dans la commande ci-dessous, uploader_type peut être restic ou kopia.

    kubectl get deploy -n velero -ojson \
| sed "s#\"image\"\: \"velero\/velero\:v[0-9]*.[0-9]*.[0-9]\"#\"image\"\: \"velero\/velero\:v1.10.0\"#g" \
| sed "s#\"server\",#\"server\",\"--uploader-type=$uploader_type\",#g" \
| sed "s#default-volumes-to-restic#default-volumes-to-fs-backup#g" \
| sed "s#default-restic-prune-frequency#default-repo-maintain-frequency#g" \
| sed "s#restic-timeout#fs-backup-timeout#g" \
| kubectl apply -f -

  4. (Facultatif) Si vous utilisez l'ensemble de démons restic, renommez les composants correspondants.

    echo $(kubectl get ds -n velero restic -ojson) \
| sed "s#\"image\"\: \"velero\/velero\:v[0-9]*.[0-9]*.[0-9]\"#\"image\"\: \"velero\/velero\:v1.10.0\"#g" \
| sed "s#\"name\"\: \"restic\"#\"name\"\: \"node-agent\"#g" \
| sed "s#\[ \"restic\",#\[ \"node-agent\",#g" \
| kubectl apply -f -
kubectl delete ds -n velero restic --force --grace-period 0

Pour plus d'informations, reportez-vous à la section Mise à niveau vers Velero 1.10 dans la documentation de 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.5.1.

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.10.3 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.6.2_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.2.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.6.2_vmware.1,projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.2.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 détecter et récupérer à partir de certains types courants de dérive.

Pour réduire la dérive, VMware recommande d'utiliser Velero pour planifier des sauvegardes fréquentes et 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.

Régénération des fichiers kubeconfig après la restauration

Lorsque vous utilisez Velero pour restaurer un cluster de charge de travail, vous devez distribuer son nouveau fichier kubeconfig à toute personne qui l'utilise :

  1. Régénérez kubeconfig :

    tanzu cluster kubeconfig get CLUSTER-NAME --namespace NAMESPACE

  2. Distribuez la sortie de la commande ci-dessus à tous ceux qui utilisent les clusters, afin de remplacer leur ancien fichier kubeconfig.

Terminer la restauration

Pour restaurer un cluster de gestion autonome et les objets du cluster de charge de travail qu'il gère, recréez le cluster de gestion à partir de son fichier de configuration, utilisez Velero pour restaurer ses clusters de charge de travail et distribuez de nouveaux fichiers kubeconfig aux personnes qui les utilisent :

  1. Si vous suspectez une dérive entre la sauvegarde la plus récente des objets de cluster de charge de travail et leur état d'exécution actuel, utilisez l'outil Détecteur de dérive pour générer un rapport de correction, comme décrit dans la section Utilisation du détecteur de dérive.

  2. Assurez-vous que toutes les modifications de configuration qui ont été apportées au cluster de gestion après son déploiement initial sont appliquées dans son fichier de configuration ou dans les variables d'environnement. Sinon, il ne sera pas restauré à son état le plus récent.

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

    • Si vous avez déployé le cluster de gestion ou ses clusters de charge de travail sur plusieurs zones de disponibilité sur vSphere, comme décrit dans la section Exécution de clusters sur plusieurs zones de disponibilité, incluez également le fichier avec les définitions d'objets VSphereFailureDomain et VSphereDeploymentZone, par exemple en incluant --az-file vsphere-zones.yaml dans la commande tanzu mc create.

  4. 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.26.8---vmware.2-tkg.1  v1.26.8+vmware.1-tkg.1  True        True

  5. 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.24.17---vmware.2-tkg.2  v1.24.17+vmware.2-tkg.2  True        True
v1.25.13---vmware.1-tkg.1  v1.25.13+vmware.1-tkg.1  True        True
v1.26.8---vmware.2-tkg.1   v1.26.8+vmware.1-tkg.1   True        True

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

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

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

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

  10. 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.26.8+vmware.1   <none>  prod  v1.26.8---vmware.2-tkg.1

  11. 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.26.8+vmware.1 <none>  v1.26.8---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

    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.

  12. Si vous avez exécuté le détecteur de dérive avant de recréer le cluster de gestion, corrigez ou examinez manuellement les objets signalés dans le rapport du détecteur de dérive, comme décrit dans la section Corriger la dérive.

  13. Régénérez et distribuez de nouveaux fichiers kubeconfig pour le cluster de gestion et ses clusters de charge de travail :

    1. Régénérez le cluster de gestion kubeconfig :

      tanzu management-cluster kubeconfig get

    2. Pour chaque cluster de charge de travail, régénérez sa kubeconfig:

      tanzu cluster kubeconfig get CLUSTER-NAME --namespace NAMESPACE

    3. Distribuez les sorties des commandes ci-dessus à tous ceux qui utilisent les clusters, afin de remplacer leurs anciens fichiers kubeconfig.

Gestion des dérives

Il se produit une dérive lorsque des objets de cluster sont modifiés depuis 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é.

Pour réduire la dérive, VMware recommande de planifier des sauvegardes fréquentes et régulières.

Pour faciliter la détection et la correction des dérives, vous pouvez utiliser l'outil Détecteur de dérive décrit dans les sections ci-dessous.

Utilisation du détecteur de dérive

Le détecteur de dérive est un outil de ligne de commande qui :

  • Compare le contenu d'une sauvegarde TKG à l'état actuel de l'infrastructure d'objets de cluster TKG, et
  • Génère un rapport qui répertorie les problèmes potentiels et les étapes de correction de la dérive
Important

Le détecteur de dérive est dans l'état Expérimental non pris en charge. La dérive est compliquée et le détecteur de dérive peut ne pas détecter toutes les instances de dérive. Il ne doit être utilisé que comme référence et jamais comme substitut pour les sauvegardes régulières.

Pour savoir comment installer et utiliser le détecteur de dérive, reportez-vous à la section Détecteur de dérive pour le cluster de gestion Tanzu Kubernetes Grid sur le site Web de la base de connaissances VMware. Le processus global est le suivant :

  1. Avant de restaurer TKG à partir d'une sauvegarde, exécutez la commande drift-detector pour générer un rapport.

  2. Téléchargez et restaurez TKG à partir de la sauvegarde la plus récente.

  3. En ce qui concerne le rapport du détecteur de dérive, suivez les instructions de la section Correction de la dérive pour prendre des mesures correctives sur l'état restauré de TKG.

Correction de la dérive

Les cas de dérive peuvent être compliqués, mais si vous disposez d'un rapport du détecteur de dérive, ou que vous détectez une dérive dans l'état de votre objet de cluster depuis la dernière sauvegarde, vous pouvez corriger certains modèles courants comme suit :

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