¿Por qué mi pod de Amazon EKS está atascado en el estado ContainerCreating y aparece el error «failed to create pod sandbox»?

Solución

Requisitos previos

Determina qué pod tiene un problema. Sigue estos pasos:

1. Ejecuta el siguiente comando para enumerar los pods de tu clúster e identificar los pods en el estado ContainerCreating:

   kubectl get pods --all-namespaces -o wide

2. Ejecuta el siguiente comando para recuperar los detalles de cada pod en el estado ContainerCreating:

   kubectl describe pod pod-name -n pod-namespace

   Nota: Sustituye pod-name por el nombre del pod y pod-namespace por el espacio de nombres en el que se encuentra el pod.

3. Revisa el resultado en la sección Eventos para identificar los pods y, a continuación, usa las siguientes secciones para solucionar el problema.

Error «Resource temporarily unavailable»

Si la configuración del kernel definida para el PID o los archivos supera el límite máximo del sistema operativo (SO), aparecerá un mensaje de error similar al siguiente:

«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»

Para resolver el problema de forma temporal, reinicia el nodo.

Para solucionar el problema, completa los siguientes pasos:

1. Reúne los registros de nodos de Containerd y Kubelet.
   Para Windows, conéctate a la instancia. Abre una línea de comandos de PowerShell y, a continuación, utiliza el script del recopilador de registros de EKS de Windows para recopilar los registros de los nodos de trabajo. Para más información, consulte EKS Logs Collector (Windows) (Recopilador de registros de EKS [Windows]) en el sitio web de GitHub. Ejecuta el siguiente comando:

   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

   En Linux, conéctate a la instancia. A continuación, utiliza el script del recopilador de registros de EKS de Linux para recopilar los registros de los nodos de trabajo. Para más información, consulte EKS Logs Collector (Linux) (Recopilador de registros de EKS [Linux]) en el sitio web de GitHub. Ejecuta el siguiente comando para descargar el script del recopilador de registros:

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

2. A continuación, ejecuta el script descargado:

   sudo bash eks-log-collector.sh

3. Revisa el registro de Kubelet para determinar si están presentes las siguientes respuestas de error:
   «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. Identifica los procesos zombis y, a continuación, detén los que no sean necesarios.
   Para Windows, abre el Administrador de tareas y, a continuación, selecciona la pestaña Detalles. Comprueba los procesos que muestran el estado Sin respuesta para identificar los procesos zombis.
   En Linux, ejecuta el siguiente comando ps para comprobar si hay procesos zombis enumerados en el estado Z:

   ps aux | egrep "Z|defunct"

   Para más información, consulta How to kill Zombie processes on Linux (Cómo eliminar los procesos zombis en Linux) en el sitio web de Linux Journal.

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

Si la interfaz de red de contenedores (CNI) no puede asignar una dirección IP al pod recién creado, es posible que recibas el siguiente mensaje de error:

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

Este error puede producirse por varios motivos, que se clasifican principalmente en tres categorías:

Limitaciones de recursos:

• IP de subred agotadas
• Se ha alcanzado el límite máximo de elementos adjuntos de ENI

Problemas de configuración:

• Falta la política CNI de IAM en los nodos de trabajo
• El pod CNI de VPC (aws-node) no está en estado En ejecución
• Versiones sin actualizar de CNI de VPC, kube-proxy o CoreDNS
• Grupos de seguridad o listas de control de acceso mal configurados

Desafíos específicos de la arquitectura:

• La configuración CNI de VPC no está alineada con tu caso de uso
• Falta la configuración de OpenID Connect (OIDC)
• Complementos autoadministrados en lugar de complementos administrados por EKS

Para ver los pasos detallados de solución de problemas, consulte ¿Cómo soluciono los problemas de los complementos kubelet o CNI para Amazon EKS?

Se recomienda hacer lo siguiente:

• Usa redes personalizadas para tu CNI de VPC que te permitan implementar pods en subredes alternativas.
• Activa el modo de delegación de prefijos. Para más información, consulta Modo de prefijo para Windows.
• Usa Grupo de seguridad de pods para asignar grupos de seguridad personalizados a varios pods a través de ENI de ramificación en un nodo de trabajo.

Nota: Si realizas algún cambio en la configuración de CNI, debes reiniciar los nodos afectados para que los cambios surtan efecto.

Error «Error while dialing»

Si el pod aws-node no se pudo comunicar con IPAM porque el pod aws-node no se pudo ejecutar en el nodo, aparecerá un error similar al siguiente:

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

El error se produce en los siguientes escenarios:

CNI de VPC en estado Pendiente

Los errores de las pruebas de disponibilidad y preparación pueden producirse debido a errores de configuración de las reglas de seguridad o de aplicación. El agotamiento de los recursos también puede provocar retrasos. Normalmente, los errores pueden producirse si DISABLE_TCP_EARLY_DEMUX se establece en «false» con POD_SECURITY_GROUP_ENFORCING_MODE en modo estricto.

Si utilizas grupos de seguridad por pod y pruebas de disponibilidad o preparación, establece DISABLE_TCP_EARLY_DEMUX en «true» en modo estricto. Esto permite que kubelet use TCP para conectarse a los pods en las interfaces de red de ramificación.

Problemas con los complementos administrados por CNI

aws-node no pasa las pruebas cuando se agrega como complemento administrado en la consola de administración de AWS. Esto ocurre porque los complementos administrados sobrescriben la cuenta de servicio.

Para solucionar este problema, realiza una de las siguientes acciones:

• Elimina el complemento administrado de la consola de administración de AWS. A continuación, vuelve a crearlo con el rol de IAM correcto que proporcione la política de IAM requerida de AmazonEKS_CNI_Policy.
• Edita la cuenta de servicio aws-node existente para asociarla al rol de IAM correcto que tenga los permisos de CNI necesarios.
• Si usas Pod Identity en el clúster, crea la asociación de identidades de pod necesaria que vincule la cuenta de servicio aws-node con el rol de IAM que usará el CNI de VPC.

**Recomendaciones adicionales: **

• Usa las versiones más recientes del CNI de VPC (aws-node), kube-proxy y coredns.

Error «Failed to setup network for sandbox»

Si utilizas Habilitar la delegación de prefijos en tus pods de VPC-CNI (aws-node), es posible que recibas el siguiente mensaje de error:

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

Para más información sobre este problema, consulta los registros del daemon de administración de direcciones IP (IPAMD) en /var/log/aws-routed-eni/ipamd.log en tu nodo de trabajo.

Incluso si la subred tiene direcciones IP disponibles, si la subred no tiene ningún bloque /28 contiguo de IP disponible, se produce un error. El error se produce cuando la fragmentación de las direcciones IP secundarias existentes se extiende por una subred. El error aparece en el complemento CNI de Amazon VPC para los registros de Kubernetes o en los eventos de CloudTrail del nodo de trabajo afectado. Es posible que se muestre el siguiente mensaje de error:

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

Usa una de las siguientes opciones para resolver este error:

Crea una nueva subred y, a continuación, inicia los pods en ella.

O bien:

Usa una reserva de CIDR de subred de Amazon EC2 para reservar espacio en una subred y usarlo con una asignación de prefijos.

Si pasas de la asignación de direcciones IP a la asignación de prefijos IP, crea nuevos grupos de nodos. A continuación, puedes aumentar la cantidad de direcciones IP disponibles en lugar de realizar un reemplazo continuo de los nodos existentes.

Si ejecutas pods en un nodo que tiene asignadas direcciones IP y prefijos, puedes provocar incoherencias en la capacidad de direcciones IP anunciadas. Este escenario puede afectar a las cargas de trabajo futuras en el nodo. Para resolver este problema, sigue los pasos descritos en Asignación de más direcciones IP a los nodos de Amazon EKS con prefijos.

Error «Pod does not have label» en nodos de Windows

Si un pod no tiene un elemento nodeSelector programado en un nodo de Windows, es posible que recibas un mensaje de error similar al siguiente:

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

Para resolver el problema, asegúrate de incluir las siguientes etiquetas en el elemento PodSpec del parámetro nodeSelector:

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

Confirma que has establecido el parámetro enable-windows-ipam en true en tu mapa de configuración de amazon-vpc-cni.

Si no tienes un mapa de configuración de amazon-vpc-cni, usa la siguiente plantilla y cárgala en el clúster:

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

Reinicia los pods aws-node y node-windows.

Para más información sobre cómo implementar nodos de Windows en clústeres de Amazon EKS, consulta Implementación de nodos de Windows en clústeres de EKS.

Error en el grupo de seguridad

Si tienes un problema con un grupo de seguridad, aparece un error similar al siguiente:

«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.»

Esta respuesta de error puede indicar un problema con el plano de control de health.kubernetes. Para resolver este problema, ponte en contacto con AWS Support.

Información relacionada

¿Cómo soluciono los problemas de los complementos kubelet o CNI para Amazon EKS?

¿Cómo soluciono los problemas de un proveedor de OIDC e IRSA en Amazon EKS?

¿Cómo soluciono los errores de IRSA en Amazon EKS?

Configuración del complemento de CNI de Amazon VPC para usar IRSA - Amazon EKS

Roles de IAM para cuentas de servicio