Pourquoi mon pod Amazon EKS est-il bloqué à l'état ContainerCreating et affiche l'erreur « failed to create pod sandbox (Impossible de créer l'environnement de test du pod) » ?

Dernière mise à jour : 30/11/2021

Mon pod Amazon Elastic Kubernetes Service (Amazon EKS) est bloqué à l'état ContainerCreating et affiche l'erreur « failed to create pod sandbox (Impossible de créer l'environnement de test du pod) ».

Solution

Vos pods Amazon EKS peuvent être bloqués à l'état ContainerCreating et afficher une erreur de connectivité réseau pour plusieurs raisons. Utilisez les étapes de dépannage suivantes en fonction du message d'erreur qui s'affiche.

Réponse d'erreur du démon : échec du démarrage de shim: fork/exec /usr/bin/containerd-shim : ressource temporairement indisponible : inconnue

Cette erreur se produit en raison d'une limitation du système d'exploitation provoquée par les paramètres du noyau définis pour le PID maximum ou le nombre maximum de fichiers.

Récupérez les informations relatives à votre pod en exécutant la commande suivante :

$ kubectl describe pod example_pod

Le résultat doit être similaire à ce qui suit :

kubelet, ip-xx-xx-xx-xx.xx-xxxxx-x.compute.internal  Failed to create pod sandbox: rpc error: code = Unknown desc = failed to start sandbox container for pod "example_pod": Error response from daemon: failed to start shim: fork/exec /usr/bin/containerd-shim: resource temporarily unavailable: unknown

Pour résoudre temporairement le problème, redémarrez le nœud.

Pour corriger le problème, procédez comme suit :

  • Rassemblez les journaux des nœuds.
  • Consultez les journaux Docker pour l'erreur « dockerd[4597]: runtime/cgo: pthread_create failed: Resource temporarily unavailable (Ressource temporairement indisponible) ».
  • Consultez le journal Kubelet pour les erreurs « kubelet[5267]: runtime: failed to create new OS thread (échec de la création d'un nouveau thread OS) (have 2 already; errno=11) » et « kubelet[5267]: runtime: may need to increase max user processes (peut avoir besoin d'augmenter le nombre maximum de processus utilisateur) (ulimit -u) ».
  • Identifiez les processus zombies en exécutant la commande ps. Tous les processus répertoriés avec l'état Z dans le résultat sont des processus zombies.

Le plugin réseau cni n'a pas pu configurer le réseau du pod : add cmd: failed to assign an IP address to container (échec de l'attribution d'une adresse IP au conteneur)

Cette erreur indique que l'interface réseau de conteneur (CNI) ne peut pas attribuer d'adresse IP au pod nouvellement alloué.

Récupérez les informations relatives à votre pod en exécutant la commande suivante :

$ kubectl describe pod example_pod

Le résultat doit être similaire à ce qui suit :

Warning FailedCreatePodSandBox 23m (x2203 over 113m) kubelet, ip-xx-xx-xx-xx.xx-xxxxx-x.compute.internal (combined from similar events): Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" network for pod "provisioning-XXXXXXXXXXXXXXX": networkPlugin cni failed to set up pod "provisioning-XXXXXXXXXXXXXXX" network: add cmd: failed to assign an IP address to container

Consultez le sous-réseau pour déterminer s'il n'a plus d'adresses IP libres. Vous pouvez consulter les adresses IP disponibles pour chaque sous-réseau dans la console Amazon VPC dans la section Subnets (Sous-réseaux).

Pour résoudre ce problème, réduisez une partie de la charge de travail afin de libérer les adresses IP disponibles. Vous pouvez choisir de mettre à l'échelle le nœud si une capacité de sous-réseau supplémentaire est disponible. Vous pouvez également créer un sous-réseau supplémentaire. Pour plus d'informations, veuillez consulter Créer des sous-réseaux avec une nouvelle plage d'adresses CIDR dans la section Comment utiliser plusieurs plages d'adresses CIDR avec Amazon EKS ?

Erreur lors de la composition du numéro tcp 127.0.0.1:50051: connect: connection refused (connexion refusée)

Cette erreur indique que le pod aws-node n'a pas réussi à communiquer avec IPAM.

Récupérez les informations relatives à votre pod en exécutant les commandes suivantes :

$ kubectl describe pod example_pod
$ kubectl describe pod/aws-node-XXXXX -n kube-system

Le résultat doit être similaire à ce qui suit :

Warning  FailedCreatePodSandBox  51s  kubelet, ip-xx-xx-xx-xx.ec2.internal  Failed create pod sandbox: rpc error: code = Unknown desc = [failed to set up sandbox container "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" network for pod "example_pod": NetworkPlugin cni failed to set up pod "example_pod" network: add cmd: Error received from AddNetwork gRPC call: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:50051: connect: connection refused", failed to clean up sandbox container
"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" network for pod "example_pod": NetworkPlugin cni failed to teardown pod "example_pod" network: del cmd: error received from DelNetwork gRPC call: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:50051: connect: connection refused"]

Pour résoudre ce problème, exécutez la commande suivante pour afficher le dernier message de journal :

kubectl -n kube-system exec -it aws-node-XXX-- tail -f /host/var/log/aws-routed-eni/ipamd.log | tee ipamd.log

Le dernier message de journal est similaire à ce qui suit :

Getting running pod sandboxes from \"unix:///var/run/dockershim.sock\

Ce message indique que le pod n'a pas pu monter var/run/dockershim.sock.

Pour résoudre ce problème, suivez les étapes ci-dessous :

  • Redémarrez le pod aws-node. Le redémarrage peut aider le pod à remapper le point de montage.
  • Si le problème n'est toujours pas résolu, coordonnez le nœud et mettez à l'échelle les nœuds du groupe de nœuds.
  • Essayez de mettre à niveau le CNI du Virtual Private Cloud (VPC) vers la dernière version prise en charge du cluster.

Si le CNI a été ajouté en tant que module complémentaire géré dans la console de gestion AWS, alors le pod aws-node échoue aux sondes. Le passage aux modules complémentaires gérés écrase le compte de service. Toutefois, le compte de service n'est pas configuré avec le rôle sélectionné. Pour résoudre ce problème, désactivez le module complémentaire de la console et créez le compte de service à l'aide d'un fichier manifeste. Vous pouvez également modifier le compte de service aws-node actuel pour ajouter le rôle utilisé sur le module complémentaire géré.

Le CNI du plugin réseau n'a pas réussi à configurer le réseau « example_pod » du pod network: failed to parse Kubernetes (échec de l'analyse de Kubernetes) args: pod does not have label (le pod n'a pas de balise) vpc.amazonaws.com/PrivateIPv4Address

Cette erreur s'affiche soit parce que le pod ne fonctionne pas correctement, soit parce que le certificat qu'il utilise n'a pas été créé correctement. Cette erreur concerne le webhook du contrôleur d'admission VPC requis sur les clusters Amazon EKS pour exécuter des charges de travail Windows. Ce composant est un plugin qui exécute un pod dans l'espace de noms kube-system. Ce composant s'exécute sur les nœuds Linux et permet la mise en réseau des pods entrants sur les nœuds Windows.

Récupérez les informations relatives à votre pod en exécutant la commande suivante :

$ kubectl describe pod example_pod

Le résultat doit être similaire à ce qui suit :

Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" network for pod "<POD_ANME>": networkPlugin cni failed to set up pod "example_pod" network: failed to parse Kubernetes args: pod does not have label vpc.amazonaws.com/PrivateIPv4Address

Pour résoudre ce problème, exécutez la commande suivante pour confirmer que le pod du contrôleur d'admission VPC est créé :

$ kubectl get pods -n kube-system

Si le pod du contrôleur d'admission n'est pas créé, activez la prise en charge Windows de votre cluster.

Important : Amazon EKS prend actuellement en charge les groupes de nœuds Windows sans que le contrôleur VPC ne soit activé. Si le contrôleur VPC est activé, supprimez la prise en charge Windows héritée de votre plan de données.

Exécutez la commande suivante pour vérifier s'il existe des erreurs enregistrées dans les journaux :

$ kubectl logs your-admission-webhook-name -n kube-system

Vous pouvez poursuivre le dépannage en fonction des erreurs identifiées dans les journaux.


Cet article vous a-t-il été utile ?


Besoin d'aide pour une question technique ou de facturation ?