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.
kubectl
Pour nettoyer votre état kubectl
en supprimant certains ou l'ensemble de ses utilisateurs, contextes et clusters :
Ouvrez votre fichier ~/.kube/config
.
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
.
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
.
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
.
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
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.
grafana.secret.*
du fichier de configuration généré.Créez un secret manuellement.
kubectl create secret generic grafana -n tanzu-system-dashboards --from-literal=admin=admin
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
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 :
|
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.2, 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. |
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.
StorageClass
entraîne l'échec du rapprochement dans les clusters de charge de travailProblè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.
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
.
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
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
Connectez-vous au cluster et supprimez les machines worker :
kubectl delete machine worker1 worker2
Dans vCenter, mettez hors tension et supprimez les machines virtuelles du nœud worker.
Modifiez les machines du plan de contrôle et supprimez le lien du finaliseur :
finalizers:
- machine.cluster.x-k8s.io
Supprimez les machines du plan de contrôle :
kubectl delete machine controlplane1 controlplane2
Dans vCenter, mettez hors tension et supprimez les machines virtuelles du plan de contrôle.
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 :
ip link
et comparez les valeurs de MTU de l'interface eth0
. Si elles ne correspondent pas, cela confirme ce problème.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
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.
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.
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.
Assurez-vous de configurer les mêmes paramètres MTU pour tous les nœuds d'un cluster.
Les paramètres de pare-feu réseau doivent autoriser l'utilisation de paquets de la taille de MTU configurée.
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
.
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.