Si vous ne parvenez pas à provisionner un cluster TKGS, consultez cette liste d'erreurs courantes à dépanner.

Vérifier les journaux d'API du cluster

Si vous ne pouvez pas créer de cluster TKG, vérifiez le bon fonctionnement de CAPW/V.

Le contrôleur CAPW/V est l'implémentation spécifique à l'infrastructure de l'API du cluster. CAPW/V est activé via le Superviseur. CAPW/V est un composant de TKG et est responsable de la gestion du cycle de vie des clusters TKG.

CAPW/V est responsable de la création et de la mise à jour de VirtualNetwork. La création des nœuds de cluster peut se poursuivre uniquement si VirtualNetwork est prêt. Le workflow de création du cluster a-t-il réussi cette phase ?

CAPW/V est responsable de la création et de la mise à jour de VirtualMachineService. VirtualMachineService a-t-il été correctement créé ? A-t-il obtenu l'adresse IP externe ? Le workflow de création du cluster a-t-il réussi cette phase ?

Pour répondre à ces questions, consultez le journal d'API comme suit : 
kubectl config use-context tkg-cluster-ns
kubectl get pods -n vmware-system-capw  | grep capv-controller
kubectl logs -n vmware-system-capw -c manager capv-controller-manager-...

Erreur de validation de la spécification du cluster

Conformément à la spécification YAML, le caractère espace peut être utilisé dans un nom de clé. Il s'agit d'une chaîne scalaire contenant un espace et ne nécessite pas de guillemets.

Toutefois, la validation TKGS n'autorise pas l'utilisation du caractère espace dans les noms de clé. Dans TKGS, un nom de clé valide doit être composé uniquement de caractères alphanumériques, d'un tiret (tel que key-name), d'un trait de soulignement (tel que KEY_NAME) ou d'un point (tel que key.name).

Si vous utilisez le caractère espace dans un nom de clé dans la spécification du cluster, le cluster TKGS n'est pas déployé. Le journal vmware-system-tkg-controller-manager affiche le message d'erreur suivant :

Invalid value: \"Key Name\": a valid config key must consist of alphanumeric characters, '-', '_' or '.' (e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')"

Pour corriger l'erreur, supprimez entièrement le caractère espace ou remplacez-le par un caractère pris en charge.

Erreurs lors de l'application du fichier YAML du cluster TKG

Si vous recevez des erreurs lors de l'application du fichier YAML du cluster TKG, résolvez les problèmes comme suit.
Le réseau de cluster n'est pas à l'état correct
Comprenez le workflow de provisionnement du cluster TKG :
  • CAPV crée un objet VirtualNetwork pour chaque réseau de cluster TKG.
  • Si le Superviseur est configuré avec la mise en réseau NSX, NCP surveille les objets VirtualNetwork et crée un routeur NSX de niveau 1 et un segment NSX pour chaque réseau virtuel.
  • CAPV vérifie l'état de VirtualNetwork et, lorsqu'il est prêt, passe à l'étape suivante du workflow.

Le contrôleur de service de VM surveille les objets personnalisés créés par CAPV et utilise ces spécifications pour créer et configurer les machines virtuelles qui constituent le cluster TKG.

NSX Container Plugin (NCP) est un contrôleur qui surveille les ressources réseau ajoutées à etcd via l'API Kubernetes et orchestre la création d'objets correspondants dans NSX.

Chacun de ces contrôleurs s'exécute en tant qu'espaces Kubernetes sur le plan de contrôle du Superviseur. Pour résoudre les problèmes de réseau, consultez le journal du contrôleur CAPV, le journal du service de VM et le journal NCP.

Vérifiez les journaux du conteneur, où name-XXXX est le nom d'espace unique lorsque vous exécutez 
kubectl get pods -A
kubectl logs pod/name-XXXXX -c pod-name -n namesapce
Nombre de nœuds de plan de contrôle non valide

Le cluster TKG sur le Superviseur prend en charge 1 ou 3 nœuds de plan de contrôle. Si vous entrez un nombre différent de réplicas, le provisionnement du cluster échoue.

Classe de stockage non valide pour le plan de contrôle/la VM worker
Exécutez la commande suivante : 
kubectl describe ns <tkg-clsuter-namesapce>

Assurez-vous qu'une classe de stockage a été attribuée à l'espace de noms dans lequel vous tentez de créer le cluster TKG. Il doit y avoir un ResourceQuota dans l'Espace de noms vSphere faisant référence à cette classe de stockage et la classe de stockage doit exister dans le Superviseur.

Assurez-vous que le nom correspond à la classe de stockage présente dans le Superviseur. Exécutez la commande kubectl get storageclasses du Superviseur en tant qu'administrateur vSphere. WCP peut transformer le nom lors de l'application du profil de stockage au Superviseur (par exemple, les traits d'union deviennent des traits de soulignement).

Classe de VM non valide

Assurez-vous que la valeur fournie dans le cluster YAML correspond à l'une des classes de machine virtuelle renvoyées par kubectl get virtualmachineclass. Seules les classes liées peuvent être utilisées par un cluster TKG. Une classe de machine virtuelle est liée lorsque vous l'ajoutez à l'Espace de noms vSphere.

La commande kubectl get virtualmachineclasses renvoie toutes les classes de machine virtuelle sur le Superviseur, mais seules les classes liées peuvent être utilisées.

Impossible de trouver les distributions TKR
Si un message d'erreur semblable au message suivant s'affiche : 
“Error from server (unable to find Kubernetes distributions): 
admission webhook “version.mutating.tanzukubernetescluster.run.tanzu.vmware.com” 
denied the request: unable to find Kubernetes distributions”

Cela est probablement dû à un problème de bibliothèque de contenu. Pour répertorier vos éléments disponibles, utilisez la commande kubectl get virtualmachineimages -A. Il en résulte les éléments disponibles et synchronisés ou chargés dans votre bibliothèque de contenu.

Pour TKG sur le Superviseur, de nouveaux noms TKR sont compatibles avec la nouvelle API TKR. Assurez-vous de nommer correctement chaque TKR dans la bibliothèque de contenu.

Nom dans la bibliothèque de contenu : photon-3-amd64-vmi-k8s-v1.23.8---vmware.2-tkg.1-zshippable

Nom correspondant dans la spécification du cluster TKG : version: v1.23.8+vmware.2-tkg.1-zshippable

Le YAML TKG est appliqué, mais aucune machine virtuelle n'est créée

Si le fichier YAML du cluster TKG 2.0 est valide et appliqué, mais que les machines virtuelles de nœud ne sont pas créées, résolvez les problèmes comme suit.
Vérifier les ressources CAPI/CAPV

Vérifiez si TKG a créé les ressources de niveau CAPI/CAPV.

  • Vérifiez si CAPV a créé les ressources VirtualMachine.
  • Vérifiez les journaux de l'opérateur de machine virtuelle pour voir pourquoi la machine virtuelle n'a pas été créée. Par exemple, le déploiement OVF peut avoir échoué en raison de ressources insuffisantes sur l'hôte ESX.
  • Vérifiez les journaux CAPV et de VM Operator.
  • Vérifiez les journaux NCP. NCP est responsable de la réalisation de VirtualNetwork, VirtualNetworkInterface et LoadBalancer pour le plan de contrôle. En cas d'erreur liée à ces ressources, il peut y avoir un problème.
Erreur de services de machine virtuelle
Erreur de services de machine virtuelle
  • Exécuter kubectl get virtualmachineservices dans votre espace de noms
  • Un service de machine virtuelle a-t-il été créé ?
  • Exécuter kubectl describe virtualmachineservices dans votre espace de noms
  • Y a-t-il des erreurs signalées sur le service de machine virtuelle ?
Erreur de réseau virtuel

Exécutez kubectl get virtualnetwork dans votre espace de noms.

Le réseau virtuel est-il créé pour ce cluster ?

Exécutez kubectl describe virtual network dans votre espace de noms.

L'interface réseau virtuelle est-elle créée pour la machine virtuelle ?

Le plan de contrôle du cluster TKG n'est pas en cours

Si le plan de contrôle TKG n'est pas en cours d'exécution, vérifiez si les ressources étaient prêtes lorsque l'erreur s'est produite. S'agit-il d'un plan de contrôle de nœud de jonction qui n'est pas actif ou d'un nœud d'initialisation ? Vérifiez également si l'ID de fournisseur n'est pas défini dans l'objet de nœud.
Vérifier si les ressources étaient prêtes lorsque l'erreur s'est produite

En plus de rechercher dans les journaux, la vérification de l'état des objets associés ControlPlaneLoadBalancer vous aidera à déterminer si les ressources étaient prêtes lorsque l'erreur s'est produite. Reportez-vous à la section Dépannage du réseau.

S'agit-il d'un plan de contrôle de nœud de jonction qui n'est pas actif ou d'un nœud d'initialisation ?

Les jonctions de nœuds ne fonctionnent pas correctement. Consultez les journaux des nœuds pour une machine virtuelle particulière. Les nœuds worker et de plan de contrôle du cluster peuvent être manquants si le nœud d'initialisation ne s'exécute pas correctement.

L'ID de fournisseur n'est pas défini dans l'objet de nœud

Si la machine virtuelle est créée, vérifiez si elle dispose d'adresses IP, puis consultez les journaux cloud-init (les commandes kubeadm sont correctement exécutées)

Consultez les journaux du contrôleur CAPI pour voir s'il existe un problème. Vous pouvez vérifier cela à l'aide de la commande kubectl get nodes sur le cluster TKG, puis vérifiez si l'ID de fournisseur existe sur l'objet de nœud.

Les nœuds worker TKG ne sont pas créés

Si le cluster TKG et les machines virtuelles du plan de contrôle sont créés, mais qu'aucun worker n'est créé ou qu'aucun autre objet de machine virtuelle n'a été créé, essayez ce qui suit : 
kubectl describe cluster CLUSTER-NAME

Recherchez des ressources de machine virtuelle dans l'espace de noms, d'autres ressources ont-elles été créées ?

Si ce n'est pas le cas, consultez les journaux CAPV pour déterminer pourquoi les autres données de démarrage d'objets de machine virtuelle non disponibles ne sont pas créées.

Si CAPI ne peut pas communiquer avec le plan de contrôle du cluster TKG via l'équilibrage de charge, qu'il s'agisse de NSX avec l'adresse IP de la VM de nœud, ou de VDS avec l'équilibrage de charge externe, procurez-vous le fichier kubeconfig du cluster TKG à l'aide du secret de l'espace de noms :

Obtenez le fichier kubeconfig du cluster TKG à l'aide du secret de l'espace de noms : 
kubectl get secret -n <namespace> <tkg-cluster-name>-kubeconfig -o jsonpath='{.data.value}' | base64 -d 
> tkg-cluster-kubeconfig; kubectl --kubeconfig tkg-cluster-kubeconfig get pods -A

Si l'opération échoue avec le message « Connexion refusée », votre plan de contrôle n'a probablement pas été initialisé correctement. En cas de délai d'expiration d'E/S, vérifiez la connectivité à l'adresse IP dans kubeconfig.

NSX avec équilibrage de charge intégré :

  • Vérifiez que l'équilibrage de charge du plan de contrôle est actif et accessible.
  • Si l'équilibrage de charge ne dispose pas d'une adresse IP, consultez les journaux NCP et consultez l'interface utilisateur de NSX-T pour voir si les composants associés sont dans des états corrects. (L'équilibrage de charge NSX-T, VirtualServer et ServerPool doivent tous être dans un état sain).
  • Si l'équilibrage de charge dispose d'une adresse IP, mais n'est pas accessible (curl -k https://<LB- VIP>:6443/healthz doit renvoyer une erreur non autorisée).

    Si l'état de l'adresse IP externe du type de service LoadBalancer est « En attente », vérifiez que le cluster TKG peut communiquer avec l'API Kubernetes du superviseur via l'adresse IP virtuelle de l'équilibrage de charge du superviseur. Assurez-vous qu'il n'y a pas de chevauchement d'adresses IP.

Vérifiez si les nœuds du plan de contrôle TKG sont dans un état sain :
  • Vérifiez si le plan de contrôle du cluster TKG signale une erreur (par exemple, impossible de créer un nœud avec l'ID de fournisseur).
  • Le fournisseur de cloud du cluster TKG n'a pas marqué le nœud avec l'ID de fournisseur correct, CAPI ne peut donc pas comparer l'ID de fournisseur dans le nœud de cluster invité et la ressource de machine dans le cluster superviseur à vérifier.
Connectez-vous via SSH à la machine virtuelle du plan de contrôle ou utilisez le fichier kubeconfig du cluster TKG pour vérifier si l'espace Cloud Provider Pod TKG est en cours d'exécution ou a consigné des erreurs. Reportez-vous à la section Connexion à des clusters Service TKG en tant qu'administrateur Kubernetes et utilisateur système. 
kubectl get po -n vmware-system-cloud-provider
kubectl logs -n vmware-system-cloud-provider <pod name>

Si le VMOP n'a pas réussi à rapprocher VirtualMachineService, consultez le journal de l'opérateur de machine virtuelle.

Si NCP a rencontré des problèmes lors de la création de ressources NSX-T, consultez le journal NCP.

Si le plan de contrôle ne s'est pas correctement initialisé, déterminez l'adresse IP de la machine virtuelle. L'état doit contenir l'adresse IP de la machine virtuelle. 
kubectl get virtualmachine -n <namespace> <TKC-name>-control-plane-0 -o yaml
ssh vmware-system-user@<vm-ip> -i tkc-cluster-ssh
Vérifiez si kubeadm a consigné des erreurs. 
cat /var/log/cloud-init-output.log | less

Cluster TKG provisionné bloqué dans la phase « Création »

Exécutez les commandes suivantes pour vérifier l'état du cluster.

kubectl get tkc -n <namespace>
kubectl get cluster -n <namespace> 
kubectl get machines -n <namespace>
KubeadmConfig était présent, mais CAPI n'a pas pu le trouver. Vérification du fait que le jeton dans vmware-system-capv disposait des autorisations appropriées pour interroger kubeadmconfig. 
$kubectl --token=__TOKEN__ auth can-i get kubeadmconfig 
yes
Il est possible que le cache controller-runtime n'ait pas été mis à jour. Les caches de surveillance CAPI peuvent être périmés et ne récupèrent pas les nouveaux objets. Si nécessaire, redémarrez capi-controller-manager pour résoudre le problème. 
kubectl rollout restart deployment capi-controller-manager -n vmware-system-capv

Espace de noms vSphere bloqué dans la phase « Arrêt en cours »

Vérifiez que TKR, le superviseur et vCenter sont synchronisés du point de vue de la compatibilité de version.

Les espaces de noms ne peuvent être supprimés que lorsque toutes les ressources sous les espaces de noms sont supprimées à leur tour. 
kubectl describe namespace NAME

L'erreur suivante a été trouvée : « Erreur du serveur (impossible de trouver les distributions Kubernetes) : le Webhook d'admission « version.mutating.tanzukubernetescluster.run.tanzu.vmware.com » a refusé la requête : impossible de trouver les distributions Kubernetes »

Vérifiez les images de machine virtuelle sur vCenter. 
kubectl get virtualmachineimages -A