Dépannage des problèmes de cluster de charge de travail

Cette section inclut des conseils pour vous aider à dépanner les clusters de charge de travail.

Pour plus d'informations sur le dépannage des déploiements de clusters de gestion autonomes, reportez-vous à la section Dépannage des clusters de gestion. Vous trouverez une solution supplémentaire aux problèmes connus de cette version dans les Notes de mise à jour ou dans les articles de la base de connaissances VMware.

Tâches courantes

Supprimer des utilisateurs, des contextes et des clusters avec kubectl

Pour nettoyer votre état kubectl en supprimant certains ou l'ensemble de ses utilisateurs, contextes et clusters :

1. Ouvrez votre fichier ~/.kube/config.

2. Pour les objets user que vous souhaitez supprimer, exécutez la commande suivante :

   kubectl config unset users.USER-NAME
   

   Où USER-NAME est la propriété name de chaque objet user de niveau supérieur, comme indiqué dans les fichiers config.

3. Pour les objets context que vous souhaitez supprimer, exécutez la commande suivante :

   kubectl config unset contexts.CONTEXT-NAME
   

   Où CONTEXT-NAME est la propriété name de chaque objet context de niveau supérieur, comme indiqué dans les fichiers config, généralement au format contexts.mycontext-admin@mycontext.

4. Pour les objets cluster que vous souhaitez supprimer, exécutez la commande suivante :

   kubectl config unset clusters.CLUSTER-NAME
   

   Où CLUSTER-NAME est la propriété name de chaque objet cluster de niveau supérieur, comme indiqué dans les fichiers config.

5. Si les fichiers config répertorient le contexte actuel sous la forme d'un cluster que vous avez supprimé, annulez le contexte :

   kubectl config unset current-context
   

Modules

Secret non créé lors de l'installation de Grafana à partir du fichier YAML par défaut

Problème

Si vous tentez d'installer Grafana en générant un fichier de configuration Grafana par défaut, l'installation échoue avec error: Secret in version "v1" cannot be handled as a Secret: illegal base64 data at input byte 4 (reason: BadRequest).

Solution

Créez le secret manuellement et utilisez le même fichier YAML sans la balise du secret pour installer Grafana.

1. Effectuez les étapes décrites dans la section Déployer Grafana dans le cluster de charge de travail pour créer le fichier de votre configuration Grafana.
2. Supprimez les entrées grafana.secret.* du fichier de configuration généré.

3. Créez un secret manuellement.

   kubectl create secret generic grafana -n tanzu-system-dashboards  --from-literal=admin=admin
   

4. Déployez le module.

   tanzu package install grafana \
   --package grafana.tanzu.vmware.com \
   --version AVAILABLE-PACKAGE-VERSION \
   --values-file grafana-data-values.yaml \
   --namespace TARGET-NAMESPACE
   

5. Effectuez les étapes restantes dans la section Déployer Grafana dans le cluster de charge de travail.

Erreur lors de l'exécution de tanzu package repository

Problème

La commande tanzu package repository échoue avec une erreur.

Solution

Exécutez kubectl get pkgr REPOSITORY-NAME -n NAMESPACE -o yaml​ pour obtenir des détails sur l'erreur.

Où :

• REPOSITORY-NAME est le nom du référentiel de modules.
• NAMESPACE est l'espace de noms cible du référentiel de modules.

La commande tanzu package repository peut échouer avec une erreur semblable à la suivante :

Erreur	Description	Solution
NOT_FOUND	Le chemin d'accès à l'URL du référentiel n'est pas valide.	Assurez-vous que l'URL du référentiel de modules est accessible depuis votre cluster.
UNKNOWN ou UNAUTHORIZED	Cette erreur peut se produire lors de la tentative de connexion au référentiel.
Ownership	Un référentiel avec la même URL de référentiel de modules est déjà installé dans le cluster.	Effectuez l'une des opérations suivantes : Exécutez tanzu package available list -n NAMESPACE pour voir si le module que vous souhaitez installer est déjà disponible pour l'installation. Pour restaurer la tentative d'ajout du référentiel actuellement en échec, exécutez tanzu package repository delete REPOSITORY-NAME -n NAMESPACE. Exécutez tanzu package repository list -A pour récupérer un référentiel de modules existant avec la même URL. Si vous récupérez le référentiel de modules, vous pouvez procéder à sa suppression à vos propres risques.

Erreur lors de l'exécution de tanzu package installed

Problème

La commande tanzu package installed échoue avec une erreur.

Solution

Exécutez kubectl get pkgi INSTALLED-PACKAGE-NAME -n NAMESPACE -o yaml​ pour obtenir des détails sur l'erreur.

Où :

• INSTALLED-PACKAGE-NAME est le nom du module installé.
• NAMESPACE est l'espace de noms du module disponible.

La commande tanzu package installed peut échouer avec une erreur semblable à la suivante :

Erreur	Description	Solution
Ownership	Un module portant le même nom est déjà installé dans le cluster.	Exécutez la commande tanzu package installed list -A pour vérifier si le module que vous souhaitez installer est déjà installé. Si c'est le cas, vous pouvez utiliser le module déjà installé, mettre à jour sa version ou supprimer le module pour pouvoir poursuivre l'installation.
Evaluating starlark template	Cette erreur peut se produire lorsque la valeur de configuration répertoriée est manquante.	Exécutez la commande tanzu package available get AVAILABLE-PACKAGE-NAME/VERSION -n NAMESPACE --values-schema pour afficher toutes les valeurs de configuration disponibles et fournir les valeurs de configuration requises à la commande tanzu package install.
Failed to find a package with name PACKAGE-NAME in namespace NAMESPACE	Les métadonnées de module et de module spécifiées ne sont pas disponibles dans l’espace de noms cible.	Assurez-vous que le module spécifié est répertorié dans la sortie de tanzu package available list AVAILABLE-PACKAGE-NAME -n NAMESPACE​. Si ce n'est pas le cas, ajoutez le référentiel de modules qui contient le module à l'espace de noms cible.
Namespace NAMESPACE not found	L'espace de noms dans lequel vous souhaitez installer le module n'existe pas.	Dans TKG v2.1 et versions ultérieures, les commandes tanzu package sont basées sur kctrl et ne prennent plus en charge l'indicateur —create-namespace. Avant d'installer un module ou un référentiel de modules, l'espace de noms cible doit déjà exister.
Provided service account SERVICE-ACCOUNT-NAME is already used by another package in namespace NAMESPACE​	Le compte de service fourni avec l'indicateur service-account-name est déjà utilisé par un autre module installé.	Autorisez le plug-in de module à créer le compte de service pour vous ou choisissez un autre nom de compte de service.

Espaces

Des espaces sont bloqués en attente sur le cluster en raison de la connectivité vCenter

Problème

Lorsque vous exécutez kubectl get pods -A sur le cluster créé, certains espaces restent en attente.

Vous exécutez la commande kubectl describe pod -n pod-namespace pod-name sur un espace affecté et vous voyez l'événement suivant :

n node(s) had taint {node.cloudprovider.kubernetes.io/uninitialized: true}, that the pod didn't tolerate

Solution

Assurez-vous que des règles de connectivité et de pare-feu sont en place pour assurer la communication entre le cluster et vCenter. Pour connaître les conditions requises en matière de ports et de protocoles de pare-feu, reportez-vous aux listes vSphere 8 dans la section VMware Ports and Protocols.

Stockage

La modification de l'objet par défaut StorageClass entraîne l'échec du rapprochement dans les clusters de charge de travail

Problème

La modification des propriétés d'un objet StorageClass par défaut inclus dans TKG entraîne un échec du rapprochement des modules dans les clusters de charge de travail qui utilisent la classe de stockage.

Solution :

pour personnaliser une classe de stockage, créez une définition StorageClass avec une valeur name au lieu de modifier la définition d'objet par défaut, puis reconfigurez le cluster pour utiliser la nouvelle classe de stockage.

Clusters de charge de travail

Le déploiement d'un cluster expire, mais le cluster est créé

Problème

L'exécution de tanzu cluster create échoue avec une erreur de délai d'expiration semblable à la suivante :

I0317 11:11:16.658433 clusterclient.go:341] Waiting for resource my-cluster of type *v1beta1.Cluster to be up and running
E0317 11:26:16.932833 common.go:29]
Error: unable to wait for cluster and get the cluster kubeconfig: error waiting for cluster to be created (this may take a few minutes): cluster control plane is still being initialized
E0317 11:26:16.933251 common.go:33]

Solution

Utilisez l'indicateur --timeout pour spécifier le délai d'attente avant la fin de la création du cluster. Le temps d'attente par défaut est de 30 minutes.

tanzu cluster create --timeout TIME

Où TIME correspond à la durée nécessaire, en minutes, pour achever la création du cluster. Par exemple, 60m.

La suppression du cluster de charge de travail est bloquée

Problème

tanzu cluster delete ne parvient pas à supprimer le cluster de charge de travail.

Pour supprimer le cluster manuellement, consultez les deux solutions ci-dessous.

Solution 1

1. Sur le cluster cible, supprimez l'objet StatefulSet pour AKO, qui s'exécute dans l'espace de noms avi-system :

   kubectl delete sts ako -n avi-system
   

Solution 2

1. Connectez-vous au cluster et supprimez les machines worker :

   kubectl delete machine worker1 worker2
   

2. Dans vCenter, mettez hors tension et supprimez les machines virtuelles du nœud worker.

3. Modifiez les machines du plan de contrôle et supprimez le lien du finaliseur :

   finalizers:
    - machine.cluster.x-k8s.io
   

4. Supprimez les machines du plan de contrôle :

   kubectl delete machine controlplane1 controlplane2
   

5. Dans vCenter, mettez hors tension et supprimez les machines virtuelles du plan de contrôle.

Nœuds worker du cluster dans l'état NotReady en raison de paramètres MTU discordants

Problème

Des paramètres d'unité de transmission maximale (MTU) différents sur les nœuds worker d'un cluster entraînent l'expiration du délai d'établissement de liaison TLS.

Les journaux de journalctl -u kubelet sur un nœud indiquent un échec de communication avec le serveur d'API. L'exécution de kubectl get nodes indique que les nœuds worker sont passés à l'état NotReady.

Vous pouvez confirmer le problème en procédant comme suit :

1. Sur les machines du nœud du plan de contrôle et du nœud worker, exécutez ip link et comparez les valeurs de MTU de l'interface eth0. Si elles ne correspondent pas, cela confirme ce problème.
2. Exécutez Crash Diagnostics (Crashd) et examinez les journaux kubelet pour déterminer que les connexions ont expiré ou que les nœuds worker sont dans l'état NotReady. Pour plus d'informations sur l'exécution de Crashd, reportez-vous à la section Dépannage de clusters de charge de travail avec Crash Diagnostics.

3. Vérifiez que les commandes suivantes échouent lorsque vous les exécutez sur une machine, dont l'état du nœud est NotReady :

   • openssl s_client -connect IP:PORT

   • curl IP:PORT -k /healthz

   Où IP et PORT sont l'adresse IP et le numéro de port du point de terminaison du plan de contrôle du serveur d'API Kubernetes. Par défaut, la variable PORT est définie sur 6443.

Solution

1. Vérifiez les DaemonSets privilégiés déployés sur le cluster et examinez tous les DaemonSets de fournisseurs tiers susceptibles de modifier les configurations réseau du système d'exploitation hôte. Vous devrez peut-être consulter le fournisseur du logiciel pour vous en assurer. Les DaemonSets qui peuvent modifier le système d'exploitation hôte auront .spec.template.spec.hostNetwork: true, ou auront privileged: true ou NET_ADMIN dans le champ Capacités (Capabilities) de n'importe quel contexte de sécurité de conteneur.

2. Si vous souhaitez configurer des paramètres MTU importants, provisionnez le cluster avec un plan de contrôle ayant une valeur de MTU plus élevée.

3. Assurez-vous que le réseau de cluster autorise la détection de MTU de chemin ou qu'il dispose d'une restriction MSS TCP pour permettre un dimensionnement de MTU correct pour les services externes, tels que les registres de vCenter ou de conteneur.

4. Assurez-vous de configurer les mêmes paramètres MTU pour tous les nœuds d'un cluster.

5. Les paramètres de pare-feu réseau doivent autoriser l'utilisation de paquets de la taille de MTU configurée.

Avec NSX ALB, vous ne pouvez pas créer de clusters avec des noms identiques

Problème

Si vous utilisez NSX Advanced Load Balancer pour les charges de travail (AVI_ENABLE) ou le plan de contrôle (AVI_CONTROL_PLANE_HA_PROVIDER), le contrôleur Avi peut ne pas parvenir à distinguer les clusters portant des noms identiques.

Solution :

définissez une valeur CLUSTER_NAME unique pour chaque cluster. ne créez pas plusieurs clusters de charge de travail qui ont la même valeur CLUSTER_NAME et se trouvent également dans le même espace de noms de cluster de gestion, tel que défini par leur valeur NAMESPACE.

La suppression du volume vSphere CSI peut échouer sur AVS

Problème

Sur la Azure vSphere Solution (AVS), la suppression des volumes persistants vSphere CSI peut échouer. La suppression d'un volume persistant nécessite l'autorisation cns.searchable. Le compte d'administrateur par défaut pour AVS, <[email protected]>, n'est pas créé avec cette autorisation. Pour plus d'informations, reportez-vous à la section Rôles et privilèges dans vSphere.

Solution

pour supprimer un volume persistant vSphere CSI sur AVS, contactez le support Azure.

La suppression du cluster sur AWS échoue si le cluster utilise des ressources de mise en réseau non déployées avec Tanzu Kubernetes Grid

Problème

Les commandes tanzu cluster delete et tanzu management-cluster delete peuvent se bloquer avec des clusters qui utilisent des ressources de mise en réseau créées par AWS Cloud Controller Manager indépendamment du processus de déploiement Tanzu Kubernetes Grid. Ces ressources peuvent inclure des équilibrages de charge et d'autres services de mise en réseau, comme indiqué dans la section The Service Controller de la documentation du fournisseur de cloud AWS Kubernetes.

Pour plus d'informations, reportez-vous à la section Problème de l'API de cluster Drain workload clusters of service Type=Loadbalancer on teardown.

Solution

utilisez kubectl delete pour supprimer des services de type LoadBalancer du cluster. Si cela échoue, utilisez la console AWS pour supprimer manuellement tous les objets LoadBalancer et SecurityGroup créés pour ce service par Cloud Controller Manager.

Attention :

Ne supprimez pas les équilibrages de charge ou les groupes de sécurité gérés par Tanzu, qui comportent les balises key: sigs.k8s.io/cluster-api-proider-aws/cluster/CLUSTER-NAME,value: owned.

Échec de la suppression du cluster lorsque le volume de stockage utilise un compte avec un point de terminaison privé

Problème

Avec un cluster de charge de travail Azure dans un groupe de ressources non géré, lorsque le pilote CSI Azure crée un volume persistant qui utilise un compte de stockage avec un point de terminaison privé, il crée une ressource privateEndpoint et une ressource vNet qui ne sont pas supprimées lorsque le volume persistant est supprimé. Par conséquent, la suppression du cluster échoue avec une erreur telle que subnets failed to delete. err: failed to delete resource ... Subnet management-cluster-node-subnet is in use.

Solution :

avant de supprimer le cluster Azure, supprimez manuellement l'interface réseau du point de terminaison privé du compte de stockage :

1. Dans un navigateur, connectez-vous à Azure Resource Explorer.
2. Cliquez sur Abonnements (Subscriptions) à gauche et développez votre abonnement.
3. Sous votre abonnement, développez resourceGroups à gauche, puis développez le groupe de ressources de votre déploiement TKG.
4. Sous le groupe de ressources, développez fournisseurs (providers) > Microsoft.Network > networkinterfaces.
5. Sous networkinterfaces, sélectionnez la ressource de carte réseau dont la suppression échoue.
6. Cliquez sur le bouton Lecture/Écriture (Read/Write) en haut, puis sur l'onglet Actions(POST, DELETE) juste en dessous.
7. Cliquez sur Supprimer.
8. Une fois la carte réseau supprimée, supprimez le cluster Azure.