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 (sandbox) du pod) ?

Dernière mise à jour : 09/01/2023

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 (sandbox) 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.

Error response from daemon: failed to start shim: fork/exec /usr/bin/containerd-shim: resource temporarily unavailable: unknown

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

Afin d'obtenir des informations concernant votre pod, exécutez la commande suivante :

$ kubectl describe pod example_pod

Exemple de sortie :

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

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

Afin de résoudre le problème, procédez comme suit :

  • Collectez 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 détecter les erreurs suivantes :
    • « kubelet [5267] : exécution : impossible de créer un nouveau thread du système d'exploitation (j'en ai déjà 2 ; errno=11) »
    • « kubelet [5267] : exécution : il faudra peut-être augmenter le nombre maximum de processus utilisateur (ulimit -u) ».
  • Identifiez les processus zombies en exécutant la commande ps. L'ensemble des processus répertoriés avec l'état Z dans la sortie sont des processus zombies.

Network plugin cni failed to set up pod network: add cmd: failed to assign an IP address to container

Cette erreur indique que le plugin Container Network Interface (CNI) ne peut pas attribuer d'adresse IP au pod nouvellement provisionné.

Ci-dessous, vous trouverez les raisons pour lesquelles le CNI ne parvient pas à fournir d'adresse IP au pod nouvellement créé :

  • L'instance a utilisé le maximum d'interfaces réseau Elastic et d'adresses IP autorisées.
  • Le nombre d'adresses IP des sous-réseaux Amazon Virtual Private Cloud (Amazon VPC) est nul.

Voici un exemple d'épuisement d'adresses IP d'interface réseau :

Instance type    Maximum network interfaces    Private IPv4 addresses per interface    IPv6 addresses per interface
t3.medium        3                             6                                       6

Dans cet exemple précédent, l'instance t3.medium possède au maximum trois interfaces réseau, et chaque interface réseau possède au maximum six adresses IP. La première adresse IP est utilisée pour le nœud et n'est pas attribuable. Il reste donc 17 adresses IP que l'interface réseau peut attribuer.

Les journaux du démon de gestion des adresses IP locales (ipamD) affichent le message suivant lorsque l'interface réseau est à court d'adresses IP :

"ipamd/ipamd.go:1285","msg":"Total number of interfaces found: 3 "
"AssignIPv4Address: IP address pool stats: total: 17, assigned 17"
"AssignPodIPv4Address: ENI eni-abc123 does not have available addresses"

Afin d'obtenir des informations concernant votre pod, exécutez la commande suivante :

$ kubectl describe pod example_pod

Exemple de sortie :

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

Vérifiez le sous-réseau afin de déterminer s'il est à court d'adresses IP libres. Vous pouvez consulter les adresses IP disponibles pour chaque sous-réseau à l'aide de la console Amazon VPC, dans la section Subnets (Sous-réseaux).

Subnet: XXXXXXXXXX
IPv4 CIDR Block 10.2.1.0/24   Number of allocated ips 254   Free address count 0

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

Error while dialing dial tcp 127.0.0.1:50051: connect: connection refused

Cette erreur indique que le pod aws-node n'a pas pu communiquer avec l'IPAM parce que le pod aws-node n'a pas pu s'exécuter sur le nœud.

Afin d'obtenir des informations concernant le pod, exécutez les commandes suivantes :

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

Exemples de sorties :

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"]

Afin de résoudre ce problème, vérifiez que le pod aws-node est déployé et que son état est Running (En cours d'exécution) :

kubectl get pods --selector=k8s-app=aws-node -n kube-system

Remarque : assurez-vous que vous exécutez la version du plugin CNI VPC adéquate pour la version du cluster.

Les pods peuvent se trouver dans l'état Pending (En attente) en raison d'erreurs liées aux probes Liveness et Readiness (tests de vitalité et de réactivité). Vérifiez que vous disposez de la dernière version du module complémentaire VPC CNI recommandée, conformément au tableau de compatibilité.

Exécutez la commande suivante afin d'afficher le dernier message de journal du pod aws-node :

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

Le problème peut également se produire parce que le point de montage Dockershim ne parvient pas à se monter. Voici un exemple de message que vous pouvez recevoir lorsque ce problème se produit :

Getting running pod sandboxes from \"unix:///var/run/dockershim.sock\
Not able to get local pod sandboxes yet (attempt 1/5): rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial unix /var/run/dockershim.sock: connect: no such file or director

Le message précédent indique que le pod n'a pas monté var/run/dockershim.sock.

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

  • Redémarrez le pod aws-node afin de remapper le point de montage.
  • Appliquez un cordon au nœud, puis redimensionnez les nœuds du groupe de nœuds.
  • Mettez à niveau l'interface réseau Amazon VPC vers la dernière version de cluster prise en charge.

Si vous avez ajouté le plugin CNI en tant que plugin géré dans la Console de gestion AWS, le aws-node échoue aux tests. Les plugins gérés remplacent le compte de service. Cependant, le compte de service n'est pas configuré avec le rôle sélectionné. Afin de résoudre ce problème, désactivez le plugin depuis la Console de gestion AWS 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 plugin géré.

Network plugin cni failed to set up pod "my-app-xxbz-zz" network: failed to parse Kubernetes args: pod does not have label vpc.amazonaws.com/PrivateIPv4Address

Cette erreur peut survenir pour les raisons suivantes :

  • Le pod ne fonctionne pas correctement.
  • Le certificat utilisé par le pod n'a pas été créé correctement.

Cette erreur concerne le webhook du contrôleur d'admission Amazon VPC requis sur les clusters Amazon EKS pour exécuter des charges de travail Windows. Le webhook est un plugin qui exécute un pod dans l'espace de noms kube-system. Le composant s'exécute sur des nœuds Linux et permet la mise en réseau des pods entrants sur les nœuds Windows.

Afin d'obtenir la liste des pods concernés, exécutez la commande suivante :

kubectl get pods

Exemple de sortie :

my-app-xxx-zz        0/1     ContainerCreating   0          58m   <none>            ip-XXXXXXX.compute.internal   <none>
my-app-xxbz-zz       0/1     ContainerCreating   0          58m   <none>

Afin d'obtenir des informations sur le pod, exécutez la commande suivante :

$ kubectl describe pod my-app-xxbz-zz

Exemple de sortie :

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
Reconciler worker 1 starting processing node ip-XXXXXXX.compute.internal.
Reconciler checking resource vpc.amazonaws.com/PrivateIPv4Address warmpool size 1 desired 3 on node ip-XXXXXXX.compute.internal.
Reconciler creating resource vpc.amazonaws.com/PrivateIPv4Address on node ip-XXXXXXX.compute.internal.
Reconciler failed to create resource vpc.amazonaws.com/PrivateIPv4Address on node ip-XXXXXXX.compute.internal: node has no open IP address slots.

Les nœuds Windows prennent en charge une interface réseau par nœud. Chaque nœud Windows peut exécuter autant de pods que le nombre d'adresses IP disponibles par interface réseau, moins un. Afin de résoudre ce problème, augmentez le nombre de nœuds Windows.

Si les adresses IP ne sont pas à l'origine du problème, consultez les événements et journaux du pod du contrôleur d'admission Amazon VPC.

Afin de confirmer que le pod du contrôleur d'admission Amazon VPC est créé, exécutez la commande suivante :

$ kubectl get pods -n kube-system  OR kubectl get pods -n kube-system | grep "vpc-admission"

Exemple de sortie :

vpc-admission-webhook-5bfd555984-fkj8z     1/1     Running   0          25m

Afin d'obtenir des informations sur le pod, exécutez la commande suivante :

$ kubectl describe pod vpc-admission-webhook-5bfd555984-fkj8z -n kube-system

Exemple de sortie :

  Normal  Scheduled  27m   default-scheduler  Successfully assigned kube-system/vpc-admission-webhook-5bfd555984-fkj8z to ip-xx-xx-xx-xx.ec2.internal
  Normal  Pulling    27m   kubelet            Pulling image "xxxxxxx.dkr.ecr.xxxx.amazonaws.com/eks/vpc-admission-webhook:v0.2.7"
  Normal  Pulled     27m   kubelet            Successfully pulled image "xxxxxxx.dkr.ecr.xxxx.amazonaws.com/eks/vpc-admission-webhook:v0.2.7" in 1.299938222s
  Normal  Created    27m   kubelet            Created container vpc-admission-webhook
  Normal  Started    27m   kubelet            Started container vpc-admission-webhook

Afin de vérifier les journaux du pod et détecter tout problème de configuration, exécutez la commande suivante :

$ kubectl logs vpc-admission-webhook-5bfd555984-fkj8z -n kube-system

Exemple de sortie :

I1109 07:32:59.352298       1 main.go:72] Initializing vpc-admission-webhook version v0.2.7.
I1109 07:32:59.352866       1 webhook.go:145] Setting up webhook with OSLabelSelectorOverride: windows.
I1109 07:32:59.352908       1 main.go:105] Webhook Server started.
I1109 07:32:59.352933       1 main.go:96] Listening on :61800 for metrics and healthz
I1109 07:39:25.778144       1 webhook.go:289] Skip mutation for  as the target platform is .

La sortie précédente indique que le conteneur a démarré correctement. Le pod ajoute ensuite l'étiquette vpc.amazonaws.com/PrivateIPv4Address au pod d'application. Cependant, le manifeste du pod d'application doit contenir une affinité ou un sélecteur de nœuds afin que le pod soit programmé sur les nœuds Windows.

Les autres options permettant de résoudre le problème incluent la vérification des éléments suivants :

  • Vous avez déployé le pod du contrôleur d'admission Amazon VPC dans l'espace de noms kube-system.
  • Les journaux ou les événements ne sont pas dirigés vers un certificat expiré. Si le certificat a expiré et que les pods Windows sont bloqués dans l'état de Container creating (Création du conteneur), vous devez supprimer et redéployer les pods.
  • Il n'y a aucun problème lié au délai d'attente ou au DNS.

Si vous ne créez pas le contrôleur d'admission Amazon VPC, activez la prise en charge de Windows pour votre cluster.

Important : Amazon EKS ne vous oblige pas à activer le contrôleur d'admission Amazon VPC pour prendre en charge les groupes de nœuds Windows. Si vous avez activé le contrôleur d'admission Amazon VPC, supprimez la prise en charge de Windows héritée de votre plan de données.


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


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