Comment résoudre les problèmes liés aux pods Kubernetes dans Amazon EKS ?

Résolution

Identifier l'erreur à l'origine du problème de pod

1. Pour obtenir des informations sur vos pods, exécutez la commande kubectl describe suivante :

   kubectl describe pod YOUR_POD_NAME -n YOUR_NAMESPACE

   Remarque : Remplacez YOUR_POD_NAME par le nom de votre pod et YOUR_NAMESPACE par votre espace de noms.

2. Identifiez le message d'erreur dans la section Événements de la sortie de la commande.

   Exemple de sortie :

   Events:
     Type     Reason            Age                From               Message
     ----     ------            ----               ----               -------
     Warning  FailedScheduling  24s                default-scheduler  no nodes available to schedule pods
     Warning  FailedScheduling  19s (x2 over 22s)  default-scheduler  no nodes available to schedule pods

En fonction du message d'erreur que vous recevez, utilisez la procédure de dépannage suivante pour résoudre le problème lié à votre pod.

Problèmes de montage du volume EBS

L'exemple de sortie suivant provient d'une commande kubectl describe pod ebs-pod. La sortie indique une erreur d'affinité entre nœuds de volume pour le montage de volumes Amazon Elastic Block Store (Amazon EBS) :

Name:         ebs-pod
...
Status:       Pending
...
Events:
  Type     Reason            Age                 From               Message
  ----     ------            ----                ----               -------
  Warning FailedScheduling 88s (x20 over 96m) default-scheduler 0/2 nodes are available 2 node(s) had volume node affinity conflict

L'erreur précédente se produit lorsque vous planifiez des réclamations de volume persistant (PVC) pour votre pod dans plusieurs zones de disponibilité. Vous ne pouvez pas programmer votre pod car celui-ci ne peut pas se connecter au volume depuis une autre zone de disponibilité. Pour résoudre ce problème, vous devez planifier les PVC dans une seule zone de disponibilité.

Pour résoudre l’erreur précédente, procédez comme suit :

1. Pour obtenir des informations sur tous les PVC de votre espace de noms, exécutez la commande kubectl get pvc suivante :

   kubectl get pvc -n YOUR_NAMESPACE

   Remarque : Remplacez YOUR_NAMESPACE par votre espace de noms.

2. Pour obtenir des informations sur votre volume persistant (PV), exécutez la commande kubectl get pv suivante :

   kubectl get pv

3. Pour trouver le PV qui correspond à votre PVC, exécutez la commande kubectl describe pv suivante :

   kubectl describe pv your_PV

   Remarque : Remplacez your_PV par le nom de votre PV.

4. Vérifiez que l'ID de volume que vous recevez de la commande précédente est associé à la zone de disponibilité appropriée.

5. Vérifiez le nœud où se trouve la zone de disponibilité.

En cas de conflit d'affinité entre nœuds de volume, effectuez l'une des actions suivantes :

• Utilisez des limites et des tolérances pour vous assurer que les pods qui utilisent le montage Amazon EBS sont planifiés sur le nœud approprié. Le nœud doit se trouver dans la même zone de disponibilité que le volume EBS. Pour plus d'informations, consultez la page Rejets et tolérances sur le site Web de Kubernetes.
• Utilisez StatefulSets plutôt qu’un déploiement pour créer un volume EBS unique dans la même zone de disponibilité pour chaque pod du StatefulSet. Pour plus d’informations, consultez la page StatefulSets sur le site Web de Kubernetes.

Votre pod ou StatefulSet est peut-être bloqué à l'état En attente. Cela est vrai même lorsque votre pod ou StatefulSet se trouve dans la même zone de disponibilité que le volume EBS. Pour résoudre ce problème, exécutez la commande kubectl logs suivante pour consulter les journaux des pods du pilote CSI Amazon EBS :

kubectl logs your-ebs-csi-controller -n your-kube-system -c your-csi-provisioner

Remarque : Remplacez your-ebs-csi-controller par votre contrôleur CSI Amazon EBS. Remplacez également your-kube-system par votre espace de noms prédéfini et your-csi-provisioner par un nom du conteneur que vous utiliserez pour extraire les journaux.

Erreur d'état ContainerCreating

Le message d'erreur suivant s'affiche lorsque votre pod est bloqué à l'état ContainerCreating et que le networkPlugin: cni n'attribue pas d'adresse IP à votre pod :

« Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "0fdf25254b1888afeda8bf89bc1dcb093d0661ae2c8c65a4736e473c73714c65" network for pod "test": networkPlugin cni failed to set up pod "test" network: add cmd: failed to assign an IP address to container. »

Pour résoudre l'erreur d'état ContainerCreating, effectuez les actions suivantes :

• Vérifiez si votre sous-réseau dispose d'une adresse IP disponible pour résoudre le problème. Ouvrez la console Amazon Virtual Private Cloud (Amazon VPC). Dans le volet de navigation, sous Cloud privé virtuel, choisissez Sous-réseaux.
• Vérifiez que le pod pour aws-node est à l’état En cours d'exécution. Assurez-vous également d'utiliser la dernière version prise en charge d'Amazon VPC CNI.
• Vérifiez si le nombre de pods sur l'instance a atteint le nombre maximum de pods.
• Dans le nœud où vous avez programmé votre pod, recherchez les messages d'erreur dans les journaux ipamd et dans le plug-in sous le chemin var/log/aws-routed-eni.

Erreur d'état CrashLoopBackoff

Le message d'erreur « Back-Off restart failed container » s'affiche.

Le message d'erreur précédent s'affiche car le conteneur échoue à plusieurs reprises, puis passe à l'état CrashLoopBackoff et redémarre de manière persistante dans le pod.

Les problèmes suivants peuvent entraîner des échecs répétés de démarrage du conteneur :

• Mémoire insuffisante
• Surcharge des ressources
• Erreurs de déploiement
• Problèmes de dépendance externes tels que des erreurs DNS
• Dépendances de tiers
• Défaillances au niveau du conteneur causées par des conflits de ports

Pour récupérer les erreurs dans les journaux du pod actuel, exécutez la commande kubectl logs suivante :

kubectl logs YOUR_POD_NAME -n YOUR_NAMESPACE

Remarque : Remplacez YOUR_POD_NAME par le nom de votre pod et YOUR_NAMESPACE par votre espace de noms.

Pour obtenir des erreurs dans les journaux du pod précédent qui a planté, exécutez la commande kubectl logs --previous suivante :

kubectl logs --previous YOUR_POD_NAME -n YOUR_NAMESPACE

Remarque : Remplacez YOUR_POD_NAME par le nom de votre pod et YOUR_NAMESPACE par votre espace de noms.

Erreurs d’échec de la sonde

Lorsqu'un pod plante, une erreur d’échec de la sonde s’affiche en raison d'un refus de connexion ou d'un délai d'xpiration du client.

Résoudre les problèmes liés à un refus de connexion

Si une sonde échoue en raison d'un refus de connexion, l'un des messages d'erreur suivants peut s'afficher :

• « Liveness probe failed: Get https://$POD_IP:8080/<healthcheck_path>: dial tcp POD_IP:8080: connect: connection refused. »
• « Readiness probe failed: Get https://$POD_IP:8080/<healthcheck_path>: dial tcp POD_IP:8080: connect: connection refused. »

Pour résoudre vos problèmes de connexion, procédez comme suit :

1. Pour obtenir manuellement le chemin de surveillance de l'état défini dans le manifeste du pod à partir du composant master, exécutez la commande suivante :

   [ec2-user@ip-10-5-1-12 ~]$ curl -ikv podIP:8080//your_healthcheck_path

   Remarque : Remplacez podIP par l'adresse IP de votre pod et your_healthcheck_path par le nom de votre chemin.

2. Vérifiez le chemin de surveillance de l’état défini sur le manifeste du pod pour le pod qui a échoué avec la sonde de liveness ou la sonde de readiness. Pour vérifier le chemin de surveillance de l’état, exécutez la commande suivante :

   local@bastion-host ~ % kubectl exec YOUR_POD_NAME -- curl -ikv "http://localhost:8080/your_healthcheck_path"

   Remarque : Remplacez YOUR_POD_NAME par le nom de votre pod.

3. Exécutez la même image de conteneur sur l'hôte bastion.

4. Vérifiez si vous pouvez obtenir le chemin de surveillance de l'état défini sur les sondes du manifeste. Puis, vérifiez les journaux du conteneur pour détecter les échecs, les délais d'expiration ou les erreurs.

5. Pour vérifier la présence d'erreurs dans les journaux kubelet du composant master sur lequel votre pod s'exécute, exécutez la commande journalctl suivante :

   [ec2-user@ip-10-5-1-12 ~]$ journalctl -u kubelet //optionally 'grep' with pod name

Résoudre les problèmes liés au délai d'expiration d'un client

Si une sonde échoue en raison d'un délai d'expiration du client, l'un des messages d'erreur suivants peut s'afficher :

• « Liveness probe failed: Get "http://podIP:8080/<healthcheck_path> ": context deadline exceeded (Client.Timeout exceeded while awaiting headers). »
• « Readiness probe failed: Get "http://podIP:8080/<healthcheck_path> ": context deadline exceeded (Client.Timeout exceeded while awaiting headers). »

Pour résoudre le problème du délai d'expiration du client, vérifiez si la configuration est correcte pour les sondes de liveness et les sondes de readiness de vos modules d'application.

Si vous utilisez un groupe de sécurité pour les pods et ENABLE_POD_ENI=true, vous devez désactiver le démultiplexage anticipé du protocole TCP. Cette action permet au kubelet de se connecter aux pods sur les interfaces réseau des succursales qui utilisent le protocole TCP.

Pour désactiver le démultiplexage anticipé du protocole TCP, exécutez la commande kubectl patch suivante :

kubectl patch daemonset aws-node -n kube-system \-p '{"spec": {"template": {"spec": {"initContainers": [{"env":[{"name":"DISABLE_TCP_EARLY_DEMUX","value":"true"}],"name":"aws-vpc-cni-init"}]}}}}'

Erreur ImagePullbackOff

L'erreur ImagePullbackoff se produit lorsqu'un conteneur qui s'exécute dans un pod ne parvient pas à extraire l'image requise d'un registre de conteneurs.

Les problèmes suivants peuvent également entraîner cette erreur :

• Problèmes de connectivité réseau
• Nom ou étiquette d'image incorrect
• Informations d’identification manquantes.
• Autorisations insuffisantes

Pour déterminer la cause du problème, procédez comme suit :

1. Pour connaître l’état d’un pod, exécutez la commande suivante :

   kubectl get pods -n YOUR_NAMESPACE

   Remarque : Remplacez YOUR_NAMESPACE par votre espace de noms.

2. Pour obtenir des informations sur les échecs de votre pod, exécutez la commande suivante :

   kubectl describe pod YOUR_POD_NAME -n YOUR_NAMESPACE

   Remarque : Remplacez YOUR_POD_NAME par le nom de votre pod et YOUR_NAMESPACE par votre espace de noms.

   Exemple de sortie :

   Events:
   Type     Reason     Age                From                Message
   ----     ------     ----               ----                -------
   Normal   Scheduled  18m                default-scheduler   Successfully assigned kube-system/kube-proxy-h4np6 to XXX.XXX.eu-west-1.compute.internal
   Normal   Pulling    16m (x4 over 18m)  kubelet             Pulling image "<account-id>.dkr.ecr.eu-west-1.amazonaws.com/eks/kube-proxy:v1.21.5-eksbuild.2"
   Warning  Failed     16m (x4 over 18m)  kubelet             Failed to pull image "<account-d>.dkr.ecr.eu-west-1.amazonaws.com/eks/kube-proxy:v1.21.5-eksbuild.2": rpc error: code = Unknown desc = Error response from daemon: manifest for <account-id>.dkr.ecr.eu-west-1.amazonaws.com/eks/kube-proxy:v1.21.5-eksbuild.2 not found: manifest unknown: Requested image not found

Pour résoudre l'erreur ImagePullbackoff, consultez la section Comment puis-je résoudre les erreurs ErrimagePull et ImagePullbackoff relatives à l'état du pod dans Amazon EKS ?