Comment puis-je résoudre les problèmes liés au contrôleur etcdadm dans EKS Anywhere ?

Brève description

Si vos nœuds Amazon Elastic Kubernetes Service (Amazon EKS) Anywhere rencontrent une défaillance d’amorçage, consultez les journaux pour pods etcdadm. Consultez également les journaux des pods etcd que vous avez créés pour un cluster etcd empilé.

Pour poursuivre le débogage, connectez-vous à l’une des machines virtuelles (VM) etcd. Si vous n’avez pas créé de machine virtuelle etcd avant la défaillance d’amorçage, vous ne pouvez pas utiliser la machine virtuelle pour déboguer.

Resolution

Vérification des journaux dans les pods etcadm

**Remarque :**Dans les commandes suivantes, remplacez SUFFIX par le suffixe de votre fournisseur d’amorçage. Remplacez KUBECONFIG_FILE par l’emplacement de votre fichier kubeconfig.

Après avoir créé votre cluster, vous pouvez l’utiliser avec le fichier KUBECONFIG généré dans votre répertoire local:

KUBECONFIG=${PWD}/${CLUSTER_NAME}/${CLUSTER_NAME}-eks-a-cluster.kubeconfig

Pour consulter les journaux pour etcdadm-bootstrap-provider-controller, exécutez la commande suivante :

kubectl -n etcdadm-bootstrap-provider-system logs etcdadm-bootstrap-provider-controller-SUFFIX  
    --kubeconfig=KUBECONFIG_FILE

Pour consulter les journaux du fichier etcdadm-bootstrap-provider-controller, exécutez la commande suivante :

kubectl -n etcdadm-controller-system logs etcdadm-controller-controller-manager-SUFFIX --kubeconfig=KUBECONFIG_FILE

Vérification de la présence d’un etcp empilé dans les journaux

Si vous avez créé des pods pour un cluster etcd empilé, exécutez la commande suivante pour vérifier les journaux de ces pods :

kubectl logs -n kube-system etcd-$CONTROL_PLANE_VM_IP --kubeconfig=KUBECONFIG_FILE

**Remarque :**Remplacez KUBECONFIG_FILE par l’emplacement de votre fichier kubeconfig.

Vérification des journaux des machines virtuelles

Après avoir utilisé le client kubectl pour consulter les journaux, vous pouvez également consulter les journaux sur les machines virtuelles :

1.    Connectez-vous au plan de contrôle de la machine virtuelle :

ssh -i $PRIV_KEY ec2-user@$CONTROL_PLANE_VM_IP

**Remarque :**Remplacez PRIV_KEY par votre clé privée. Remplacez CONTROL_PLANE_VM_IP par l’adresse IP de la machine virtuelle de votre plan de contrôle.

2.    Pour un système d’exploitation (OS) BottleRocket : Pour obtenir le shell racine d’un nœud qui s’exécute sur un OS BottleRocket, exécutez la commande sudo sheltie.

3.    Une fois que la connexion est établie avec une VM etcd, vous pouvez consulter d’autres journaux de conteneurs connexes à l’emplacement suivant :

cd /var/log/containers

Vérification de la présence d’un etcd non empilé ou externe dans les journaux

Pour un etcd non empilé ou externe, connectez-vous à n’importe quelle VM etcd que vous avez créée.

1.    Pour vous connecter à votre VM etcd, exécutez la commande suivante :

ssh -i $PRIV_KEY ec2-user@$ETCD_VM_IP

**Remarque :**Remplacez PRIV_KEY par votre clé privée. Remplacez ETCD_VM_IP par l’adresse IP de votre machine virtuelle.

2.    Pour un système d’exploitation (OS) BottleRocket : Pour obtenir le shell racine d’un nœud qui s’exécute sur un OS BottleRocket, exécutez la commande sudo sheltie.

3.    Une fois que la connexion est établie avec une VM etcd, vous pouvez consulter d’autres journaux de conteneurs connexes à l’emplacement suivant :

cd /var/log/containers  
bash-5.1# ls -lrt  
total 4  
lrwxrwxrwx. 1 root root 90 Apr 11 16:38 etcd-mgmt-etcd-4mt4g_kube-system_etcd-aa91be45434b920903e0630254cb5f319b86b50c56b87d8f992b0285272b93c4.log -> /var/log/pods/kube-system_etcd-mgmt-etcd-4mt4g_88b6dbc1be367b4ffc5a6bfab65e7376/etcd/0.log

Exécuter une opération de surveillance de l’état

ETCD_CONTAINER_ID=$(ctr -n k8s.io c ls | grep -w "etcd-io" | cut -d " " -f1)  
ctr -n k8s.io t exec -t --exec-id etcd ${ETCD_CONTAINER_ID} etcdctl \  
     --cacert=/var/lib/etcd/pki/ca.crt \  
     --cert=/var/lib/etcd/pki/server.crt \  
     --key=/var/lib/etcd/pki/server.key \  
     endpoint health  

127.0.0.1:2379 is healthy: successfully committed proposal: took = 10.241212ms

Exemples de messages d’erreur

Lorsque vous consultez vos journaux, vous pouvez voir divers messages d’erreur relatifs à votre défaillance d’amorçage. Les exemples suivants présentent certaines des erreurs les plus courantes :

« Waiting for External ETCD to be ready » (En attente d’un ETCD externe prêt).

Pour résoudre cette erreur, consultez la documentation troubleshooting documentation for Amazon EKS Anywhere (dépannage d’Amazon EKS Anywhere).

« Kubelet of ETCD VMs Crashing » (Échec Kubelet des machines virtuelles ETCD).

Le provisionnement du cluster ne se poursuit pas après la création de votre machine virtuelle ETCD. Ce problème se produit également avec le message d’erreur Kubelet suivant :

« Impossible de démarrer ContainerManager » err="Configuration non valide de l'allocation de nœuds. La ressource \"ephemeral-storage\" a une allocation de {{1175812097 0} {<nil>} BinarySi}, capacité de {{-155109377 0} {<nil>} BinarySI}"

Cela indique que le stockage éphémère sur le nœud ne dispose pas de suffisamment d’espace libre. Dans chaque nœud Kubernetes, le répertoire racine de kubelet (/var/lib/kubelet par défaut) et le répertoire des journaux (/var/log) se trouvent sur la partition racine du nœud.

Pour afficher l’espace libre sur le disque pour un système de fichiers spécifique, exécutez la commande suivante :

"df -h"

Pour afficher la liste de tous les fichiers et de leurs tailles respectives, exécutez la commande suivante :

"sudo du -d 3 /var/lib/"

Si vous ne disposez pas de suffisamment d’espace sur le disque, nettoyez votre nœud pour libérer de l’espace. Vous pouvez également étendre la capacité de stockage de la partition racine de votre nœud.

Informations connexes

Installer etcd (site web etcd)

Comment vérifier l’état du cluster (site web etcd)