Pour quelles raisons mon pod Amazon EKS est-il bloqué à l’état ContainerCreating avec l’erreur « failed to create pod sandbox » ?

Résolution

Prérequis

Identifiez le pod posant problème. Procédez comme suit :

1. Exécutez la commande suivante pour répertorier les pods de votre cluster afin d'identifier les pods à l'état ContainerCreating :

   kubectl get pods --all-namespaces -o wide

2. Exécutez la commande suivante pour récupérer les détails de chaque pod à l'état ContainerCreating :

   kubectl describe pod pod-name -n pod-namespace

   Remarque : remplacez pod-name par le nom de votre pod et pod-namespace par l'espace de noms dans lequel se trouve votre pod.

3. Examinez la sortie des événements pour identifier les pods, puis utilisez les sections suivantes pour résoudre votre problème.

Erreur « Resource temporarily unavailable »

Si les paramètres de noyau que vous avez définis pour le PID ou les fichiers dépassent la limite maximale du système d'exploitation (OS), un message d'erreur similaire à l’exemple suivant s'affiche :

« kubelet, ip-192-168-0-1.us-east-1.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 résoudre ce problème, procédez comme suit :

1. Rassemblez les journaux de nœuds pour Containerd et le Kubelet.
   Pour Windows, connectez-vous à votre instance. Ouvrez une invite de commande PowerShell, puis utilisez le script de collecte de journaux Windows EKS pour collecter les journaux du composant master. Pour plus d'informations, consultez la page Collecteur de journaux EKS (Windows) sur le site Web de GitHub. Exécutez la commande suivante :

   Invoke-WebRequest -OutFile eks-log-collector.ps1 https://raw.githubusercontent.com/awslabs/amazon-eks-ami/main/log-collector-script/windows/eks-log-collector.ps1
   .\eks-log-collector.ps1

   Pour Linux, connectez-vous à votre instance. Puis, utilisez le script de collecte de journaux Linux EKS pour collecter les journaux du composant master. Pour plus d'informations, consultez la page Collecteur de journaux EKS (Linux) sur le site Web de GitHub. Exécutez la commande suivante pour télécharger le script du collecteur de journaux :

   curl -O https://raw.githubusercontent.com/awslabs/amazon-eks-ami/master/log-collector-script/linux/eks-log-collector.sh

2. Puis, exécutez le script téléchargé :

   sudo bash eks-log-collector.sh

3. Consultez le journal Kubelet pour rechercher les réponses d’erreur suivantes :
   « kubelet[5267]: runtime: failed to create new OS thread (have 2 already; errno=11)""kubelet[5267]: runtime: may need to increase max user processes (ulimit -u) »

4. Identifiez les processus zombies, puis interrompez ceux qui ne sont pas nécessaires.
   Pour Windows, ouvrez le Gestionnaire des tâches, puis cliquez sur l’onglet Détails. Vérifiez les processus qui indiquent l’état Ne répond pas pour identifier les processus zombies.
   Pour Linux, exécutez la commande ps suivante pour vérifier la présence de processus zombies répertoriés à l’état Z :

   ps aux | egrep "Z|defunct"

   Pour plus d'informations, consultez la page Comment arrêter des processus zombie sous Linux sur le site Web de Linux Journal.

Erreur « Network plugin cni failed to set up pod network »

Si l'interface Container Network Interface (CNI) ne parvient pas à attribuer d'adresse IP au pod que vous venez de créer, le message d'erreur suivant peut s'afficher :

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

Cette erreur peut survenir pour plusieurs raisons, regroupées principalement en trois catégories :

Limitations de ressources :

• IP de sous-réseau épuisées
• Limite maximale d’attachement ENI atteinte

Problèmes de configuration :

• Politique CNI IAM manquante sur les composants master
• Le pod CNI VPC (aws-node) n'est pas à l’état En cours d'exécution
• Versions obsolètes de CNI VPC, kube-proxy ou CoreDNS
• Groupes de sécurité ou listes de contrôle d'accès incorrectement configurés

Défis spécifiques à l'architecture :

• Désalignement de la configuration de CNI VPC avec votre cas d'utilisation
• Configuration OpenID Connect (OIDC) manquante
• Modules complémentaires autogérés au lieu de modules complémentaires gérés par EKS

Pour des étapes de dépannage détaillées, consultez la section Comment résoudre les problèmes liés au kubelet ou au plug-in CNI pour Amazon EKS ?

Il est recommandé d’adopter les mesures suivantes :

• Utilisez un réseau personnalisé pour votre CNI VPC qui vous permet de déployer des pods sur d’autres sous-réseaux.
• Activez le mode délégation de préfixe. Pour plus d'informations, consultez la section Mode préfixe pour Windows.
• Utilisez Groupe de sécurité pour les pods afin d’attribuer des groupes de sécurité personnalisés à plusieurs pods via des ENI de branche sur un composant master.

Remarque : si vous apportez des modifications à votre configuration CNI, vous devez redémarrer les nœuds concernés pour que les modifications soient prises en compte.

Erreur « Error while dialing »

Si le pod aws-node n'a pas réussi à communiquer avec IPAM parce que le pod aws-node n'a pas pu s'exécuter sur le nœud, une erreur similaire à l’exemple suivant s’affiche :

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

L'erreur se produit dans les scénarios suivants :

CNI VPC à l’état En attente

Des défaillances des sondes Liveness and Readiness peuvent survenir en raison de la configuration des règles de sécurité ou d'erreurs d'application. L'épuisement des ressources peut également entraîner des retards. En règle générale, des échecs peuvent se produire si DISABLE_TCP_EARLY_DEMUX est défini sur faux avec POD_SECURITY_GROUP_ENFORCING_MODE en mode strict.

Si vous utilisez des groupes de sécurité par pod et des sondes Liveness ou Readiness, définissez DISABLE_TCP_EARLY_DEMUX sur vrai en mode strict. Cela permet au kubelet d'utiliser le protocole TCP pour se connecter aux pods sur les interfaces réseau de branche.

Problèmes liés aux plug-ins gérés par le CNI

Le compte de service aws-node échoue aux sondes lorsqu'il est ajouté en tant que plug-in géré dans la console de gestion AWS. Cela se produit parce que les plug-ins gérés remplacent le compte de service.

Pour résoudre ce problème, effectuez l'une des opérations suivantes :

• Supprimez le module complémentaire géré de la console de gestion AWS. Puis, recréez-le avec le rôle IAM approprié qui fournit la politique IAM AmazonEKS_CNI_Policy requise.
• Modifiez le compte de service aws-node existant pour l'associer au rôle IAM approprié disposant des autorisations CNI requises.
• Si vous utilisez Identité du pod sur le cluster, créez l'association d'identité de pod nécessaire qui lie le compte de service aws-node au rôle IAM à utiliser par le CNI VPC.

Recommandations supplémentaires :

• Utilisez les dernières versions du CNI VPC (aws-node), kube-proxy et coredns.

Erreur « Failed to setup network for sandbox »

Si vous utilisez Activer la délégation de préfixes dans vos pods VPC-CNI (aws-node), le message d'erreur suivant peut s'afficher :

« Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox »

Pour obtenir plus de détails sur ce problème, consultez les journaux d’IP Address Management Daemon (IPAMD) dans le fichier /var/log/aws-routed-eni/ipamd.log de votre composant master.

Même si votre sous-réseau compte des adresses IP disponibles, si aucun bloc /28 contigu d'adresses IP n’est disponible dans ce dernier, une erreur se produit. Cette erreur se produit lorsque la fragmentation des adresses IP secondaires existantes s'étend sur un sous-réseau. L'erreur apparaît dans le plug-in CNI Amazon VPC pour les journaux Kubernetes ou dans vos événements CloudTrail pour le composant master concerné. Le message d'erreur suivant peut s'afficher :

« InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request »

Pour résoudre cette erreur, effectuez une ou plusieurs des actions suivantes :

Créez un nouveau sous-réseau, puis lancez-y les pods.

-ou-

Utilisez également une réservation CIDR de sous-réseau Amazon EC2 pour réserver de l'espace au sein d'un sous-réseau à utiliser avec une attribution de préfixe.

Si vous passez de l'attribution d'adresses IP à l'attribution de préfixes IP, créez de nouveaux groupes de nœuds. Vous pouvez ensuite augmenter le nombre d'adresses IP disponibles plutôt que de procéder à un remplacement progressif des nœuds existants.

Si vous exécutez des pods sur un nœud auquel sont attribués à la fois des adresses IP et des préfixes, il peut en résulter une incohérence dans la capacité d'adresses IP annoncée. Ce scénario peut avoir un impact sur les charges de travail futures imposées au nœud. Pour résoudre ce problème, suivez les étapes décrites dans la section Attribuer des adresses IP supplémentaires aux nœuds Amazon EKS avec des préfixes.

Erreur « Container image authentication »

Si le moteur d'exécution du conteneur ne dispose pas des autorisations nécessaires pour extraire une image, un message d'erreur similaire au suivant peut s'afficher :

« pull access denied, repository does not exist or may require authorization: authorization failed: no basic auth credentials »

Pour résoudre cette erreur, vérifiez les points suivants :

• Examinez le rôle IAM associé au composant master EKS. Si la politique IAM AmazonEC2ContainerRegistryReadOnly est manquante, associez-la.
• Si vous extrayez des images d'un référentiel ECR depuis un compte croisé, consultez la section Comment autoriser un compte secondaire à transférer ou à extraire des images dans mes référentiels d'images Amazon ECR ? Assurez-vous que la politique au niveau du référentiel est définie avec les autorisations appropriées.
• Si vous utilisez des points de terminaison de VPC ECR pour extraire des images. Alors, assurez-vous que le groupe de sécurité des points de terminaison de VPC autorise le HTTPS entrant sur le port 443 depuis le groupe de sécurité du nœud EKS. Pour plus d'informations, consultez la section Points de terminaison de VPC de l'interface Amazon ECR (AWS PrivateLink).
• Pour containerd, le téléchargement de l’image pause n'est effectué que lors du bootstrap. L'image doit ensuite être retenue sur l'instance. N'utilisez pas de scripts de nettoyage personnalisés ni de commandes de suppression manuelles telles que crictl rmi —prune pour supprimer les images pause. Laissez kubelet gérer le récupérateur de mémoire (gc), qui s'exécute automatiquement toutes les 1 à 2 minutes. Lorsque vous supprimez des images du conteneur pause containerd, les nouveaux pods ne démarrent pas. Les pods actuels s'exécutent sans problème sur les nœuds et les journaux kubelet affichent l'erreur « Failed to create pod sandbox ».

Si vous avez supprimé l'image du conteneur pause du composant master EKS, procédez comme suit :

1. Pour vérifier si le composant master EKS contient des images pause, exécutez la commande suivante :

   ctr -n k8s.io images ls | grep -o "602401143452.dkr.ecr.YOUR-REGION.amazonaws.com/eks/pause:3.10"

   Remarque : remplacez YOUR-REGION par la région AWS.

   Si le composant master EKS contient des images pause, la sortie se présente comme suit :

   602401143452.dkr.ecr.aws.example.region.amazonaws.com/eks/pause:3.10
   602401143452.dkr.ecr.aws.example.region.amazonaws.com/eks/pause:3.10

   Pour vérifier si le composant master EKS est supprimé, exécutez la commande suivante :

   ctr -n k8s.io images ls | grep -o "localhost/kubernetes/pause:latest"

   Si les images sont supprimées, la sortie se présente comme suit :

   ctr -n k8s.io images list |grep -i pause

2. Pour extraire l'image et obtenir le jeton d'authentification ECR, exécutez les commandes suivantes :

   ECR_REGION=YOUR-REGION
   ECR_PASSWORD=$(aws ecr get-login-password --region $ECR_REGION)

   Remarque : remplacez YOUR-REGION par la région AWS.

3. Extrayez l'image pause de l'ECR. Assurez-vous que vous disposez de la version appropriée de l'image pause. Si vous n'êtes pas sûr de la version de l'image, connectez-vous à l'un de vos composants master et sélectionnez la version de l'image.

   Exemple :

   sudo ctr -n k8s.io image pull --user "AWS:$ECR_PASSWORD" 602401143452.dkr.ecr.aws.example.region.amazonaws.com/eks/pause:<ImageVersion>

   Remarque : vous pouvez sélectionner la dernière version de l'image à partir de Versions sur le site Web de GitHub.

4. Identifiez l'image comme localhost pour EKS.

   Exemple :

   sudo ctr -n k8s.io image tag 602401143452.dkr.ecr.aws.example.region.amazonaws.com/eks/pause:<ImageVersion> localhost/kubernetes/pause:latest

5. Une fois l'image pause de nouveau disponible, les nouveaux modules sont opérationnels et fonctionnent sans problème.

Erreur « Container image authentication »

Si le moteur d'exécution du conteneur ne dispose pas des autorisations nécessaires pour extraire une image, un message d'erreur similaire au suivant peut s'afficher :

« pull access denied, repository does not exist or may require authorization: authorization failed: no basic auth credentials »

Pour résoudre cette erreur, vérifiez les points suivants :

• Examinez le rôle IAM associé au composant master EKS. Si la politique IAM AmazonEC2ContainerRegistryReadOnly est manquante, associez-la.
• Si vous extrayez des images d'un référentiel ECR depuis un compte croisé, consultez la section Comment autoriser un compte secondaire à transférer ou à extraire des images dans mes référentiels d'images Amazon ECR ? Assurez-vous que la politique au niveau du référentiel est définie avec les autorisations appropriées.
• Si vous utilisez des points de terminaison de VPC ECR pour extraire des images, assurez-vous que le groupe de sécurité des points de terminaison de VPC autorise le HTTPS entrant sur le port 443 depuis le groupe de sécurité du nœud EKS. Pour plus d'informations, consultez la section Points de terminaison de VPC de l'interface Amazon ECR (AWS PrivateLink).
• Pour containerd, le téléchargement de l’image pause n'est effectué que lors du bootstrap. L'image doit ensuite être retenue sur l'instance. N'utilisez pas de scripts de nettoyage personnalisés ni de commandes de suppression manuelles telles que crictl rmi —prune pour supprimer les images pause. Laissez kubelet gérer le récupérateur de mémoire (gc), qui s'exécute automatiquement toutes les 1 à 2 minutes. Lorsque vous supprimez des images du conteneur pause containerd, les nouveaux pods ne démarrent pas. Les pods actuels s'exécutent sans problème sur les nœuds et les journaux kubelet affichent l'erreur « Failed to create pod sandbox ».

Erreur « Pod does not have label » sur les nœuds Windows

Si aucun paramètre nodeSelector n'est programmé pour un pod sur un nœud Windows, un message d'erreur similaire à l’exemple suivant peut s'afficher :

Erreurs « Failed to parse Kubernetes args: pod does not have label vpc.amazonaws.com/PrivateIPv4Address » ou « Pod does not have label vpc.amazonaws.com/PrivateIPv4Address »

Pour résoudre le problème, assurez-vous d’inclure les étiquettes suivantes dans PodSpec pour le paramètre nodeSelector :

nodeSelector:
    kubernetes.io/os: windows
    kubernetes.io/arch: amd64

Vérifiez que vous avez défini le paramètre enable-windows-ipam sur vrai dans votre configmap amazon-vpc-cni.

Si vous ne disposez pas d’un configmap amazon-vpc-cni, utilisez le modèle suivant et chargez-le sur votre cluster :

apiVersion: v1
kind: ConfigMap
metadata:
  name: amazon-vpc-cni
  namespace: kube-system
data:
  enable-windows-ipam: "true"

Redémarrez les pods aws-node et node-windows.

Pour plus d'informations sur le déploiement de nœuds Windows sur des clusters Amazon EKS, consultez la section Déployer des nœuds Windows sur des clusters EKS.

Erreur du groupe de sécurité

Si vous rencontrez un problème de groupe de sécurité, une erreur similaire à l’erreur suivante s'affiche :

« Plugin type="aws-cni" name="aws-cni" failed (add): add cmd: failed to assign an IP address to container
Vpc-resource-controller failed to allocate branch ENI to pod: creating network interface, NoCredentialProviders: no valid providers in chain. Deprecated. »

Cette réponse d’erreur peut indiquer un problème au niveau du plan de contrôle health.kubernetes. Pour résoudre ce problème, contactez AWS Support.

Informations connexes

Comment résoudre les problèmes liés au kubelet ou au plug-in CNI pour Amazon EKS ?

Comment puis-je résoudre les problèmes liés à un fournisseur OIDC et à un IRSA dans Amazon EKS ?

Comment puis-je corriger les erreurs liées aux IRSA dans Amazon EKS ?

Configurer le plug-in CNI Amazon VPC pour utiliser IRSA

Rôles IAM pour les comptes de service