Dépannage

Dépannage Cluster API

Vérification des PODS

Lorsqu’un problème survient avec Cluster API, la première chose à faire est de vérifier les PODS impliqués dans le fonctionnement de Cluster API.

Vérifiez que ces 4 PODS sont bien en STATUS Running

# kubectl get pods -A

NAMESPACE                           NAME                                                            READY   STATUS    RESTARTS   AGE
capi-kubeadm-bootstrap-system       capi-kubeadm-bootstrap-controller-manager-7dc44947-hrmvc        1/1     Running   0          36m
capi-kubeadm-control-plane-system   capi-kubeadm-control-plane-controller-manager-cb9d954f5-r8w54   1/1     Running   0          36m
capi-system                         capi-controller-manager-7594c7bc57-jr75r                        1/1     Running   0          37m
capvcd-system                       capvcd-controller-manager-89758d745-kw4sm                       1/1     Running   0          13s

Si l’un de ces PODS n’est pas en status Running, vous pouvez faire deux choses pour recueillir des informations à propos du problème :

1. Décrire le POD
2. Récupérer les journaux du POD

Example :

# kubectl describe pod capi-controller-manager-7594c7bc57-jr75r -n capi-system

and

# kubectl logs capi-controller-manager-7594c7bc57-jr75r -n capi-system

Vérifier le fournisseur CAPVCD

Si des erreurs surviennent concernant la communication avec vCloud Director pendant la création de cluster, la mise à jour de cluster, les opérations d’extension par exemple, il peut s’agir d’un problème avec le fournisseur CAPVCD.

Le POD capvcd-controller-manager dans le namespace capvcd est responsable de ces actions et des erreurs peuvent être trouvées dans ses journaux.

# kubectl logs capvcd-controller-manager-7594c7bc57-jr75r -n capvcd-system

Une option permet d’afficher plus de logs sur la communication avec vCloud Director.

Pour cela lancez la commande suivante :

kubectl set env -n capvcd-system deployment/capvcd-controller-manager GOVCD_LOG_ON_SCREEN=true -oyaml

Cette option étant très verbeuse, n’oubliez pas de retirer cette option une fois le diagnostique terminée, pour cela :

kubectl set env -n capvcd-system deployment/capvcd-controller-manager GOVCD_LOG_ON_SCREEN-

Vérifier les objets API

Cluster API utilise plusieurs types d’objets pour décrire un cluster K8S à gérer.

L’idée pour le dépannage est d’explorer les différents objets pas-à-pas afin de trouver l’objet qui a une erreur au niveau de son statut, sa description ou dans ses logs.

En fonction du composant pour lequel l’erreur survient (noeud de travail, de contrôle ou sur le cluster globalement) il est possible de choisir l’objet à explorer en se reportant au schéma ci-dessus.

• Listez les objets pour trouver le nom exact de l’objet à vérifier

# kubectl get MachineDeployment -A

• Décrire l’objet

# kubectl describe MachineDeployment mycluster-workers-0 -n mynamespace

Répétez les actions 1 & 2 pour l’ensemble des objets afin de trouver l’erreur.

Script d’export des journaux

Un script a été créé par VMware pour exporter les journaux ainsi que quelques informations sur la configuration du cluster.

generate-k8s-log-bundle.sh :

export KUBECONFIG=[PATH_TO_YOUR_KUBECONFIG]
curl -s https://raw.githubusercontent.com/vmware/cloud-provider-for-cloud-director/[YOUR_CAPVCD_VERSION]/scripts/generate-k8s-log-bundle.sh | bash -

Dépannage du déploiement des noeuds

Voici quelques éléments à contrôler sur le noeuds qui a un problème de déploiement (ne se joint pas au cluster par exemple)

Vérifier l’état sur service kubelet

systemctl status kubelet

Journalctl

journalctl -xeu containerd

journalctl -xeu kubelet

Voici les fichiers à explorer concernant le déploiement des noeuds.

Cloud-init

/var/log/cloud-init-output.log

/var/log/capvcd/customization/status.log

/var/log/capvcd/customization/error.log

containerd

/var/log/containers/*