Cette rubrique inclut des conseils pour vous aider à dépanner les déploiements de clusters de gestion autonomes.
Pour plus d'informations sur le dépannage de clusters de charge de travail, reportez-vous à la section Dépannage des problèmes de clusters de charge de travail. 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.
Certaines des procédures ci-dessous utilisent la CLI kind
. Pour installer kind
, reportez-vous à la section Installation dans la documentation kind
.
Vous pouvez utiliser SSH pour vous connecter à des nœuds individuels de clusters de gestion autonomes ou de clusters de charge de travail. Pour ce faire, la paire de clés SSH que vous avez créée lors du déploiement du cluster de gestion doit être disponible sur la machine sur laquelle vous exécutez la commande SSH. Par conséquent, vous devez exécuter les commandes ssh
sur la machine sur laquelle vous exécutez les commandes tanzu
.
Les clés SSH que vous enregistrez dans le cluster de gestion et qui sont utilisées par les clusters de charge de travail que vous déployez à partir du cluster de gestion sont associées aux comptes d’utilisateurs suivants :
capv
ubuntu
ubuntu
ec2-user
capi
Pour vous connecter à un nœud à l’aide de SSH, exécutez l’une des commandes suivantes à partir de la machine que vous utilisez comme machine de démarrage :
ssh capv@node-address
ssh ubuntu@node-address
ssh ec2-user@node-address
ssh capi@node-address
Étant donné que la clé SSH est présente sur le système sur lequel vous exécutez la commande ssh
, aucun mot de passe n'est requis.
kubectl
Pour nettoyer votre état kubectl
en supprimant certains ou l'ensemble de ses utilisateurs, contextes et clusters :
Ouvrez votre fichier ~/.kube-tkg/config
.
Pour les objets user
que vous souhaitez supprimer, exécutez la commande suivante :
kubectl config unset users.USERNAME --kubeconfig ~/.kube-tkg/config
Où USERNAME
est la propriété name
de chaque objet user
de niveau supérieur, comme indiqué dans le fichier config
.
Pour les objets context
que vous souhaitez supprimer, exécutez la commande suivante :
kubectl config unset contexts.CONTEXT-NAME --kubeconfig ~/.kube-tkg/config
Où CONTEXT-NAME
est la propriété name
de chaque objet context
de niveau supérieur, comme indiqué dans le fichier config
, généralement de la forme contexts.mycontext-admin@mycontext
.
Pour les objets cluster
que vous souhaitez supprimer, exécutez la commande suivante :
kubectl config unset clusters.CLUSTER-NAME --kubeconfig ~/.kube-tkg/config
Où CLUSTER-NAME
est la propriété name
de chaque objet cluster
de niveau supérieur, comme indiqué dans le fichier 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 --kubeconfig ~/.kube-tkg/config
Si vous avez supprimé des clusters de gestion suivis par la CLI tanzu
, supprimez-les de l'état de la CLI tanzu
en exécutant tanzu config server delete
, comme décrit dans la section Supprimer les clusters de gestion à partir de la configuration de votre CLI Tanzu.
nfs-utils
sur les nœuds Photon OSProblème
Dans Tanzu Kubernetes Grid v1.1.2 et versions ultérieures, nfs-utils
est activé par défaut. Si vous n'avez pas besoin de nfs-utils
, vous pouvez le supprimer des machines virtuelles de nœud de cluster.
Solution
Pour désactiver nfs-utils
sur les clusters que vous déployez avec Tanzu Kubernetes Grid v1.1.2 ou version ultérieure, utilisez SSH pour vous connecter aux machines virtuelles de nœud de cluster et exécutez la commande suivante :
tdnf erase nfs-utils
Problème
L'exécution de tanzu management-cluster create
ou de tanzu mc create
échoue avec une erreur semblable à la suivante :
Validating the pre-requisites...
Looking for AWS credentials in the default credentials provider chain
Error: : Tkg configuration validation failed: failed to get AWS client: NoCredentialProviders: no valid providers in chain
caused by: EnvAccessKeyNotFound: AWS_ACCESS_KEY_ID or AWS_ACCESS_KEY not found in environment
SharedCredsLoad: failed to load shared credentials file
caused by: FailedRead: unable to open file
caused by: open /root/.aws/credentials: no such file or directory
EC2RoleRequestError: no EC2 instance role found
caused by: EC2MetadataError: failed to make EC2Metadata request
Solution
Tanzu Kubernetes Grid utilise la chaîne de fournisseurs d'informations d'identification AWS par défaut. Avant de créer un cluster de gestion ou de charge de travail sur AWS, vous devez configurer vos informations d'identification de compte AWS, comme décrit dans la section Configurer les informations d'identification AWS.
Problème
Avant de créer un cluster de gestion ou de charge de travail autonome sur Azure, vous devez accepter les conditions juridiques qui concernent l'image de machine virtuelle utilisée par les nœuds de cluster. L'exécution de tanzu mc create
ou de tanzu cluster create
sans avoir accepté la licence échoue avec une erreur telle que :
User failed validation to purchase resources. Error message: 'You have not accepted the legal terms on this subscription: '*********' for this plan. Before the subscription can be used, you need to accept the legal terms of the image.
Solution
Si cela se produit, acceptez les conditions juridiques et réessayez :
Problème
Une tentative infructueuse de déploiement d'un cluster de gestion autonome laisse des objets inactifs dans votre infrastructure de cloud et sur votre machine de démarrage.
Solution
tanzu mc create
dans le terminal ou dans l'interface du programme d'installation de Tanzu Kubernetes Grid. Si la commande échoue, elle imprime un message d'aide qui inclut les éléments suivants : « Échec lors du déploiement du cluster de gestion… Pour nettoyer les ressources créées par le cluster de gestion : tkg delete mc… ».tanzu mc delete YOUR-CLUSTER-NAME
. Cette commande supprime les objets qu'elle a créés dans votre infrastructure et localement.Vous pouvez également utiliser les autres méthodes décrites ci-dessous :
Nettoyage de machine de démarrage :
Pour supprimer un cluster kind
, utilisez la CLI kind
. Par exemple :
kind get clusters
kind delete cluster --name tkg-kind-example1234567abcdef
Pour supprimer des objets Docker, utilisez la CLI docker
. Par exemple, docker rm
, docker rmi
et docker system prune -a --volumes
.
Attention :Si vous exécutez des processus Docker qui ne sont pas liés à Tanzu Kubernetes Grid sur votre système, supprimez individuellement les objets Docker inutiles.
Nettoyage de la plate-forme cible :
AZURE_RESOURCE_GROUP
. Utilisez les cases à cocher pour sélectionner et supprimer les ressources créées par Tanzu Kubernetes Grid, dont le nom contient un horodatage.Problème
Après l'exécution de tanzu mc delete
sur AWS, tanzu mc get
et d'autres commandes de la CLI Tanzu ne répertorient plus le cluster de gestion supprimé, mais :
cluster infrastructure is still being provisioned: VpcReconciliationFailed
.Solution
Ce comportement se produit lorsque TKG utilise des informations d'identification de compte AWS expirées ou non valides. Pour empêcher cette situation ou pour récupérer à partir de celle-ci :
Empêcher (Prevent) : Mettez à jour les informations d'identification du compte AWS, comme décrit dans la section Configurer les informations d'identification du compte AWS à l'aide de profils d'informations d'identification AWS ou de variables d'environnement statiques locales.
Récupérer (Recover) à l'aide du tableau de bord EC2 : Supprimer manuellement les nœuds du cluster de gestion du tableau de bord EC2
Récupérer (Recover) à l'aide de l'interface de ligne de commande (CLI) :
Dans le cluster kind
qui reste sur la machine de démarrage en raison de l'échec de la suppression du cluster de gestion, corrigez le secret des informations d'identification AWS :
kubectl get secret capa-manager-bootstrap-credentials -n capa-system -ojsonpath="{.data.credentials}"| base64 -d
Modifiez le secret afin d'inclure les informations d'identification AWS :
[default]
aws_access_key_id = <key id>
aws_secret_access_key = <access_key>
region = <region>
Exécutez de nouveau la commande tanzu mc delete
.
Problème
L'exécution de tanzu mc delete
supprime le cluster de gestion, mais ne parvient pas à supprimer le cluster local kind
de la machine de démarrage.
Solution
Répertoriez tous les clusters kind
en cours d'exécution et supprimez celui qui ressemble à tkg-kind-unique_ID
:
kind delete cluster --name tkg-kind-unique_ID
Répertoriez tous les clusters en cours d'exécution et identifiez le cluster kind
.
docker ps -a
Copiez l'ID de conteneur du cluster kind
et supprimez-le.
docker kill container-ID
Problème
Votre cluster de gestion autonome ne parvient pas à se déployer, car les machines sont bloquées, en attente de correction.
Solution
Pour un cluster de gestion que vous avez déployé avec le plan dev
, qui ne dispose que d'un seul nœud de plan de contrôle, vous devez redéployer le cluster de gestion. Pour les clusters de gestion avec plusieurs nœuds de plan de contrôle, vous pouvez identifier et supprimer les machines bloquées.
Récupérez l’état du cluster de gestion. Par exemple :
kubectl -n tkg-system get cluster my-mgmt-cluster -o yaml
Recherchez les noms des machines bloquées à partir de la sortie de l'étape précédente. Une machine bloquée est marquée comme WaitingForRemediation
. Par exemple, le nom de la machine bloquée est my-mgmt-cluster-zpc7t
dans la sortie suivante :
status:
conditions:
- lastTransitionTime: "2021-08-25T15:44:23Z"
message: KCP can't remediate if current replicas are less or equal then 1
reason: WaitingForRemediation @ Machine/my-mgmt-cluster-zpc7t
severity: Warning
status: "False"
type: Ready
Augmentez les valeurs de délai d'expiration du contrôle de santé de la machine pour les nœuds de plan de contrôle au-delà de la valeur par défaut, 5m
. Par exemple :
tanzu cluster machinehealthcheck control-plane set my-cluster --mhc-name my-control-plane-mhc --unhealthy-conditions "Ready:False:10m,Ready:Unknown:10m"
Pour plus d'informations sur la mise à jour d'un objet MachineHealthCheck
, reportez-vous à la section Créer ou mettre à jour un objet MachineHealthCheck
dans Configurer les contrôles de santé de la machine pour les clusters de charge de travail.
Définissez kubectl
sur le contexte de votre cluster de gestion. Par exemple :
kubectl config use-context mgmt-cluster-admin@mgmt-cluster
Supprimez les machines bloquées.
kubectl delete machine MACHINE-NAME
Où MACHINE-NAME
est le nom de la machine que vous avez localisée à une étape précédente.
Attendez que le contrôleur KubeadmControlPlane
redéploie la machine.
~/.config/tanzu
Problème
Le répertoire ~/.config/tanzu
sur la machine de démarrage a été supprimé ou endommagé accidentellement. La CLI Tanzu crée et utilise ce répertoire, et ne peut pas fonctionner sans celui-ci.
Solution
Pour restaurer le contenu du répertoire ~/.config/tanzu
:
Pour identifier les clusters de gestion Tanzu Kubernetes Grid existants, exécutez :
kubectl --kubeconfig ~/.kube-tkg/config config get-contexts
La sortie de la commande répertorie les noms et les contextes de tous les clusters de gestion créés ou ajoutés par la CLI Tanzu.
Pour chaque cluster de gestion répertorié dans la sortie, restaurez-le dans le répertoire ~/.config/tanzu
et la CLI en exécutant :
tanzu login --kubeconfig ~/.kube-tkg/config --context MGMT-CLUSTER-CONTEXT --name MGMT-CLUSTER
tanzu management-cluster
créé sur macOS entraîne une erreur de version kubectlProblème
Si vous exécutez la commande tanzu management-cluster create
ou tanzu mc create
sur macOS avec la dernière version stable de Docker Desktop, l'opération échoue avec le message d'erreur suivant :
Error: : kubectl prerequisites validation failed: kubectl client version v1.15.5 is less than minimum supported kubectl client version 1.25.7
Cela se produit, car Docker Desktop fait des liens symboliques avec une ancienne version de kubectl
dans le chemin d'accès.
Solution
Placez une version plus récente prise en charge de kubectl
dans le chemin avant la version de Docker.
Si vous avez perdu les informations d'identification d'un cluster de gestion autonome, par exemple, en supprimant par inadvertance le fichier .kube-tkg/config
sur le système sur lequel vous exécutez les commandes tanzu
, vous pouvez récupérer les informations d'identification à partir du nœud du plan de contrôle du cluster de gestion.
tanzu mc create
pour recréer le fichier .kube-tkg/config
.Utilisez SSH pour vous connecter au nœud de plan de contrôle du cluster de gestion.
Reportez-vous à la section Connexion aux nœuds de cluster avec SSH ci-dessus pour obtenir les informations d'identification à utiliser pour chaque plate-forme cible.
Accédez au fichier admin.conf
pour le cluster de gestion.
sudo vi /etc/kubernetes/admin.conf
Le fichier admin.conf
contient le nom du cluster, le nom d'utilisateur du cluster, le contexte du cluster et les données du certificat client.
.kube-tkg/config
sur le système sur lequel vous exécutez les commandes tanzu
.VSPHERE_CONTROL_PLANE_ENDPOINT
facticeProblème
L'intégration d'un fournisseur d'identité externe à un déploiement TKG existant peut nécessiter la définition d'une valeur de VSPHERE_CONTROL_PLANE_ENDPOINT
factice dans le fichier de configuration du cluster de gestion utilisé pour créer le secret de module complémentaire, comme décrit dans la section Générer le secret de module complémentaire Pinniped pour le cluster de gestion
Secret
sur les clusters héritésProblème
Lorsque vous désactivez la gestion des identités externes sur un cluster de gestion, l'objet Pinniped Secret
inutilisé reste présent sur les clusters de charge de travail hérités.
Si un utilisateur tente ensuite d'accéder au cluster à l'aide d'un ancien kubeconfig
, une fenêtre contextuelle de connexion s'affiche et échoue.
Solution
supprimez manuellement le code Pinniped Secret
du cluster hérité, comme décrit dans la section Désactiver la gestion des identités.
Problème
La mise à niveau vers Tanzu Kubernetes Grid v2.2 renvoie une erreur semblable à la suivante :
Operation cannot be fulfilled on certificates.cert-manager.io "pinniped-cert": the object has been modified; please apply your changes to the latest version and try again
Solution
Cette erreur peut se produire si la tâche de post-déploiement Pinniped est en conflit avec le processus de mise à niveau d'un composant. Procédez comme suit pour supprimer et redéployer la tâche.
Supprimer la tâche de post-déploiement Pinniped.
kubectl delete jobs.batch -n pinniped-supervisor pinniped-post-deploy-job
Attendez environ 5 minutes que kapp-controller
redéploie la tâche de post-déploiement.
Vérifiez l'état de l'application Pinniped.
kubectl get app -n tkg-system pinniped
NAME DESCRIPTION SINCE-DEPLOY AGE
pinniped Reconcile succeeded 5s 49m
Si la DESCRIPTION
affiche Reconciling
, attendez quelques minutes, puis vérifiez de nouveau. Une fois qu'elle affiche Reconcile succeeded
passez à l'étape suivante.
Vérifier l'état de la tâche de post-déploiement Pinniped.
kubectl get jobs -n pinniped-supervisor
NAME COMPLETIONS DURATION AGE
pinniped-post-deploy-job-ver-1 1/1 9s 62s
Problème
Vous avez mis à niveau récemment votre cluster de gestion. Lorsque vous tentez de vous authentifier sur un cluster de charge de travail associé à ce cluster de gestion, vous recevez un message d'erreur semblable au message suivant :
Error: could not complete Pinniped login: could not perform OIDC discovery for "https://IP:PORT": Get "https://IP:PORT/.well-known/openid-configuration": x509: certificate signed by unknown authority
Solution
Cela se produit, car la copie du bundle d'autorité de certification du superviseur Pinniped que le cluster de charge de travail utilise est obsolète. Pour mettre à jour le bundle d'autorité de certification du superviseur, procédez comme suit :
Définissez le contexte kubectl
sur le cluster de gestion.
Obtenez le bundle d'autorité de certification codé en base64 et le point de terminaison issuer
à partir de pinniped-info
ConfigMap :
kubectl get configmap pinniped-info -n kube-public -o jsonpath={.data.issuer_ca_bundle_data} > /tmp/ca-bundle && kubectl get configmap pinniped-info -n kube-public -o jsonpath={.data.issuer} > /tmp/supervisor-endpoint
Obtenez la section values.yaml
à partir du secret du module complémentaire Pinniped pour le cluster de charge de travail :
kubectl get secret WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml
Ce secret se trouve sur le cluster de gestion.
Dans le fichier values.yaml
créé ci-dessus, mettez à jour la clé supervisor_ca_bundle_data
pour qu'elle corresponde au bundle d'autorité de certification à partir de pinniped-info
ConfigMap. En outre, assurez-vous que le supervisor_svc_endpoint
correspond au point de terminaison issuer
.
Appliquez votre mise à jour en codant en base64 le fichier values.yaml
modifié et en le remplaçant dans le secret du cluster de charge de travail. Cette commande diffère selon le système d'exploitation de votre environnement. Par exemple :
Linux :
kubectl patch secret/WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -p "{\"data\":{\"values.yaml\":\"$(base64 -w 0 < values.yaml)\"}}" --type=merge
macOS :
kubectl patch secret/WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -p "{\"data\":{\"values.yaml\":\"$(base64 < values.yaml)\"}}" --type=merge
Sur le cluster de charge de travail, vérifiez que l'application Pinniped a correctement rapproché les modifications :
kubectl get app pinniped -n tkg-system
Authentifiez-vous sur le cluster. Par exemple :
kubectl get pods -A --kubeconfig my-cluster-credentials
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 dans la page VMware Ports and Protocols.
Problème
L'exécution des commandes de CLI tanzu
renvoie une erreur semblable à la suivante :
Failed to invoke API on cluster : the server has asked for the client to provide credentials, retrying
Solution
Reportez-vous aux sections Mettre à jour le certificat de cluster de gestion dans votre configuration de la CLI Tanzu et Impossible d'accéder aux clusters à l'aide des commandes de CLI tkg/tanzu dans Tanzu Kubernetes Grid.
Problème
Dans l'invite de commande Windows (CMD), la sortie de commande de CLI Tanzu formatée en colonnes inclut des caractères superflus dans les en-têtes de colonne. Ce problème ne se produit pas avec le terminal Windows ou PowerShell.
Solution
sur les machines de démarrage Windows, exécutez la CLI Tanzu depuis votre terminal Windows.
Problème
Lorsque les contrôles de santé de la machine (MHCs) sont désactivés, les commandes de la CLI Tanzu telles que tanzu cluster status
peuvent ne pas signaler l'état à jour du nœud pendant la recréation de l'infrastructure.
Solution
aucune.
Problème
Lorsque vous exécutez la commande tanzu management-cluster create --ui
ou tanzu mc create --ui
sur un système Windows, l'interface utilisateur s'ouvre dans votre navigateur par défaut, mais les graphiques et le style ne sont pas appliqués. Cela se produit, car un registre Windows est défini sur application/x-css
.
Solution
regedit
pour ouvrir l'utilitaire Éditeur du Registre.HKEY_CLASSES_ROOT
et sélectionnez .js
.application/javascript
, puis cliquez sur OK.tanzu mc create --ui
pour relancer l'interface utilisateur.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 gestion avec la même valeur CLUSTER_NAME
, même à partir de différentes machines de démarrage.
Problème
Si le nombre total de services de type LoadBalancer
est élevé, et si tous les moteurs de service sont déployés sur le même réseau L2, les demandes envoyées à l'adresse IP virtuelle de NSX Advanced Load Balancer peuvent échouer avec le message no route to host
.
Cela se produit, car la limite de débit ARP par défaut sur les moteurs de service est de 100.
Solution
Définissez la limite de débit ARP sur un nombre plus élevé. Ce paramètre n'est pas modifiable dans NSX Advanced Load Balancer Essentials, mais il l'est dans NSX Advanced Load Balancer Enterprise Edition.
AKODeploymentConfig
ignorée lors de la création du cluster de gestionProblème
L'exécution de tanzu management-cluster create
pour créer un cluster de gestion avec NSX ALB génère l'erreur no matches for kind ???AKODeploymentConfig??? in version ???networking.tkg.tanzu.vmware.com/v1alpha1???
.
Solution
Vous pouvez ignorer cette erreur. Pour plus d'informations, reportez-vous à cet article de la base de connaissances.
medium
et les espaces plus petits avec NSX Advanced Load BalancerProblème
Sur vSphere, les clusters de charge de travail avec des nœuds worker medium
ou plus petits exécutant le module Multus CNI avec NSX ALB peuvent échouer avec des erreurs Insufficient CPU
ou d'autres erreurs.
Solution
pour utiliser Multus CNI avec NSX ALB, déployez des clusters de charge de travail avec des nœuds worker de taille large
ou extra-large
.
Problème
Sur Azure, la mise à niveau des clusters de gestion et des clusters de charge de travail échoue avec des erreurs telles que context deadline exceeded
ou unable to upgrade management cluster: error waiting for kubernetes version update for kubeadm control plane
. Cela se produit, car les opérations sur Azure prennent parfois plus de temps que sur d'autres plates-formes.
Solution
exécutez la commande tanzu management-cluster upgrade
ou tanzu cluster upgrade
de nouveau, en spécifiant un délai d'expiration plus long dans l'indicateur --timeout
. Le délai d'expiration par défaut est 30 ms.
Problème
Dans TKG v2.2, les composants qui transforment un cluster générique en cluster de gestion autonome TKG sont intégrés dans un module Carvel tkg-pkg
. Les clusters de gestion autonomes créés à l'origine dans TKG v1.3 ou version antérieure ne disposent pas d'un secret de configuration requis par le processus de mise à niveau pour installer tkg-pkg
, ce qui entraîne l'échec de la mise à niveau.
Solution
suivez les étapes supplémentaires répertoriées dans la section Mettre à niveau des clusters de gestion autonomes pour les clusters de gestion autonomes créés dans TKG v1.3 ou version antérieure.