¿Por qué el pod de Amazon EKS se queda atascado en el estado ContainerCreating con el error “failed to create pod sandbox” (no se ha podido crear el entorno aislado del pod)?

Resolución

Es posible que los pods de Amazon EKS se queden atascados en el estado ContainerCreating con un error de conectividad de red debido a varias razones. Siga los siguientes pasos para solucionar el problema según el mensaje de error que aparezca.

Respuesta de error de daemon: no se pudo iniciar shim: fork/exec /usr/bin/containerd-shim: recurso temporalmente no disponible: desconocido

Este error se produce debido a una limitación del sistema operativo causada por la configuración del kernel definida para el PID máximo o el número máximo de archivos.

Ejecute el siguiente comando para obtener información sobre su pod:

$ kubectl describe pod example_pod

La salida es similar a la siguiente:

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

Para resolver temporalmente el problema, reinicie el nodo.

Para solucionar el problema, haga lo siguiente:

• Reúna los registros del nodo.
• Revise los registros de Docker en busca del error “dockerd[4597]: runtime/cgo: pthread_create failed: Resource temporarily unavailable”.
• Revise el registro de Kubelet para ver si hay los siguientes errores:
  • “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)”.
• Identifique los procesos zombi mediante la ejecución del comando ps. Todos los procesos que aparecen con el estado Z en la salida son los procesos zombis.

La CNI del complemento de red no pudo configurar la red del pod: add cmd: no pudo asignar una dirección IP al contenedor

Este error indica que la interfaz de red de contenedores (CNI) no puede asignar una dirección IP para el pod recién aprovisionado.

A continuación, se encuentran los motivos por los que la CNI no puede proporcionar una dirección IP al pod recién creado:

• La instancia usó la cantidad máxima permitida de interfaces de redes elásticas y direcciones IP.
• Las subredes de Amazon Virtual Private Cloud (Amazon VPC) tienen un recuento de direcciones IP igual a cero.

A continuación, se muestra un ejemplo de agotamiento de la dirección IP de la interfaz de la red:

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

En este ejemplo, la instancia t3.medium tiene un máximo de 3 interfaces de red y cada interfaz de red tiene un máximo de 6 direcciones IP. La primera dirección IP se usa para el nodo y no se puede asignar. Esto deja 17 direcciones IP que la interfaz de red puede asignar.

Los registros del daemon de administración de direcciones IP locales (ipamD) muestran el siguiente mensaje cuando la interfaz de red se queda sin direcciones 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"

Ejecute el siguiente comando para obtener información sobre su pod:

$ kubectl describe pod example_pod

La salida es similar a la siguiente:

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

Revise la subred para identificar si se ha quedado sin direcciones IP libres. Puede ver las direcciones IP disponibles de cada subred en la consola de Amazon VPC en la sección Subredes.

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

Para resolver este problema, desescale verticalmente parte de la carga de trabajo para dejar libres direcciones IP disponibles. Se puede optar por escalar el nodo si se dispone de capacidad de subred adicional. También puede crear una subred adicional. Para obtener más información, consulte How do I use multiple CIDR ranges with Amazon EKS? (¿Cómo puedo usar varios rangos de CIDR con Amazon EKS?). Siga las instrucciones de la sección Create subnets with a new CIDR range (Crear subredes con un nuevo rango de CIDR).

Se ha producido un error al marcar tcp 127.0.0.1:50051: connect: conexión rechazada

Este error indica que el pod aws-node no pudo comunicarse con el IPAM porque el pod aws-node no se ejecutó en el nodo.

Ejecute los siguientes comandos para obtener información sobre el pod:

$ kubectl describe pod example_pod

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

Las salidas son similares a las siguientes:

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

Para solucionar este problema, compruebe que el pod aws-node esté desplegado y se encuentre en el estado Running:

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

Nota: Asegúrese de ejecutar la versión correcta del complemento CNI de VPC para la versión de clúster.

Es posible que los pods estén en estado Pending (Pendiente) debido a errores de los sondeos de actividad y preparación. Asegúrese de tener la última versión recomendada del complemento CNI de VPC según la tabla de compatibilidad.

Ejecute el siguiente comando para ver el último mensaje de registro del 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

El problema también puede ocurrir porque el punto de montaje de Dockershim no se puede montar. El siguiente es un mensaje similar al que puede recibir cuando se produce este problema:

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

Este mensaje indica que el pod no pudo montar var/run/dockershim.sock.

Para resolver este problema, intente lo siguiente:

• Reinicie el pod aws-node para reasignar el punto de montaje.
• Acordone el nodo y escale los del grupo de nodos.
• Actualice la interfaz de red de Amazon VPC a la versión de clúster compatible más reciente.

Si la CNI se agregó como un complemento administrado en la Consola de administración de AWS, el nodo aws-node falla los sondeos. Los complementos administrados sobrescriben la cuenta de servicio. Sin embargo, la cuenta de servicio no está configurada con el rol seleccionado. Para resolver este problema, desactive el complemento desde la Consola y cree la cuenta de servicio con un archivo de manifiesto. Otra posibilidad es editar la cuenta de servicio actual de aws-node para agregar el rol que se usa en el complemento administrado.

La CNI del complemento de red no pudo configurar la red del pod “my-app-xxbz-zz”: no se pudieron analizar los argumentos de Kubernetes: el pod no tiene la etiqueta vpc.amazonaws.com/PrivateIPv4Address

Es posible que este error se produzca debido a una de las siguientes razones:

• El pod no se está ejecutando correctamente.
• El certificado que utiliza el pod no se ha creado correctamente.

Este error está relacionado con el webhook del controlador de admisión de Amazon VPC que se requiere en los clústeres de Amazon EKS para ejecutar cargas de trabajo de Windows. Este componente es un complemento que ejecuta un pod en el espacio de nombres kube-system. Este componente se ejecuta en nodos Linux y permite la creación de redes para los pods entrantes en nodos de Windows.

Ejecute el siguiente comando para obtener la lista de los pods afectados:

kubectl get pods

La salida es similar a la siguiente:

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>

Ejecute el siguiente comando para obtener información sobre el pod:

$ kubectl describe pod my-app-xxbz-zz

La salida es similar a la siguiente:

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.

Los nodos de Windows admiten una interfaz de red por nodo. Cada uno de los nodos de Windows pueden ejecutar tantos pods como direcciones IP haya disponibles por interfaz de red, menos uno. Para resolver este problema, escale verticalmente el número de nodos de Windows.

Si las direcciones IP no son el problema, revise el evento y los registros del pod del controlador de admisión de Amazon VPC.

Para solucionar este problema, ejecute el siguiente comando a fin de confirmar que se ha creado el pod del controlador de admisión de Amazon VPC:

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

La salida es similar a la siguiente:

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

Ejecute el siguiente comando para obtener información sobre el pod:

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

La salida es similar a la siguiente:

  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

Ejecute el siguiente comando para comprobar si hay algún problema de configuración en los registros del pod:

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

La salida es similar a la siguiente:

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 salida anterior muestra que el contenedor se inició correctamente. Luego, el pod añade la etiqueta vpc.amazonaws.com/PrivateIPv4Address al pod de la aplicación. Sin embargo, el manifiesto del pod de la aplicación debe contener un selector de nodos o una afinidad para que el pod esté programado en los nodos de Windows.

Otras opciones para solucionar el problema incluyen la verificación de lo siguiente:

• Ha implementado el pod del controlador de admisión de Amazon VPC en el espacio de nombres kube-system.
• Los registros o eventos no apuntan a un certificado caducado. Si el certificado ha caducado y los pods de Windows están atascados en el estado ContainerCreating, debe eliminar y volver a deplegar los pods.
• No hay tiempos de espera ni problemas relacionados con el DNS.

Si no crea el controlador de admisión de Amazon VPC, habilite la compatibilidad con Windows para su clúster.

Importante: Amazon EKS no requiere que active el controlador de admisión de Amazon VPC para admitir los grupos de nodos de Windows. Si ha habilitado el controlador de admisión de Amazon VPC, elimine la compatibilidad con Windows heredado de su plano de datos.

---

Información relacionada

Redes de Amazon EKS