¿Cómo soluciono los problemas de los pods de Kubernetes en Amazon EKS?

Resolución

Identificación del error que causa el problema con el pod

1. Para obtener información sobre tus pods, ejecuta el siguiente comando kubectl describe:

   kubectl describe pod YOUR_POD_NAME -n YOUR_NAMESPACE

   Nota: Sustituye YOUR_POD_NAME por el nombre de tu pod y YOUR_NAMESPACE por tu espacio de nombres.

2. Identifica el mensaje de error en la sección Eventos del resultado del comando.

   Resultado de ejemplo:

   Events:
     Type     Reason            Age                From               Message
     ----     ------            ----               ----               -------
     Warning  FailedScheduling  24s                default-scheduler  no nodes available to schedule pods
     Warning  FailedScheduling  19s (x2 over 22s)  default-scheduler  no nodes available to schedule pods

Según el mensaje de error que recibas, usa la siguiente solución de problemas para resolver el problema del pod.

Problemas de montaje de volúmenes de EBS

El siguiente resultado de ejemplo proviene de un comando kubectl describe pod ebs-pod. El resultado muestra un error de afinidad entre nodos de volumen para el montaje de volúmenes de Amazon Elastic Block Store (Amazon EBS):

Name:         ebs-pod
...
Status:       Pending
...
Events:
  Type     Reason            Age                 From               Message
  ----     ------            ----                ----               -------
  Warning FailedScheduling 88s (x20 over 96m) default-scheduler 0/2 nodes are available 2 node(s) had volume node affinity conflict

El error anterior se produce cuando programas reclamaciones de volumen persistente (PVC) para tu pod en varias zonas de disponibilidad. No puedes programar el pod porque no se puede conectar al volumen desde otra zona de disponibilidad. Para resolver este problema, debes programar las PVC en una zona de disponibilidad.

Para solucionar este problema, sigue estos pasos:

1. Para obtener información sobre todas las PVC de tu espacio de nombres, ejecuta el siguiente comando kubectl get pvc:

   kubectl get pvc -n YOUR_NAMESPACE

   Nota: Sustituye YOUR_NAMESPACE por tu espacio de nombres.

2. Para obtener información sobre tu volumen persistente (PV), ejecuta el siguiente comando kubectl get pv:

   kubectl get pv

3. Para encontrar el PV que corresponde a tu PVC, ejecuta el siguiente comando kubectl describe pv:

   kubectl describe pv your_PV

   Nota: Sustituye your_PV por el nombre de tu PV.

4. Confirma que el ID de volumen que recibes del comando anterior está asociado a la zona de disponibilidad correcta.

5. Comprueba el nodo en el que se encuentra la zona de disponibilidad.

Si se produce un conflicto de afinidad entre nodos de volumen, realiza una de las siguientes acciones:

• Usa taints y tolerancias para asegurarte de que los pods que utilizan el montaje de Amazon EBS se programen en el nodo correcto. El nodo debe estar en la zona de disponibilidad donde se encuentra el volumen de EBS. Para obtener más información, consulta Taints and tolerations (Taints y tolerancias) en el sitio web de Kubernetes.
• Utiliza StatefulSets en lugar de un despliegue para crear un volumen de EBS único en la misma zona de disponibilidad para cada pod del StatefulSet. Para obtener más información, consulta StatefulSets en el sitio web de Kubernetes.

Es posible que tu pod o StatefulSet estén bloqueados en el estado Pendiente. Esto es así incluso cuando el pod o el StatefulSet se encuentran en la misma zona de disponibilidad que el volumen de EBS. Para resolver este problema, ejecuta el siguiente comando kubectl logs para comprobar los registros de los pods del controlador de CSI de Amazon EBS:

kubectl logs your-ebs-csi-controller -n your-kube-system -c your-csi-provisioner

Nota: Sustituye your-ebs-csi-controller por tu controlador de CSI de Amazon EBS. Además, sustituye your-kube-system por tu espacio de nombres predefinido y your-csi-provisioner por un nombre de contenedor que utilices para extraer los registros.

Error de estado de ContainerCreating

El siguiente mensaje de error aparece cuando el Pod se bloquea en el estado ContainerCreating y el networkPlugin: cni no asigna una dirección IP al Pod:

«Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "0fdf25254b1888afeda8bf89bc1dcb093d0661ae2c8c65a4736e473c73714c65" network for pod "test": networkPlugin cni failed to set up pod "test" network: add cmd: failed to assign an IP address to container».

Para solucionar el error de estado de ContainerCreating, realiza las siguientes acciones:

• Comprueba si la subred tiene una dirección IP disponible para resolver el problema. Abre la consola de Amazon Virtual Private Cloud (Amazon VPC). En el panel de navegación, en Nube virtual privada, elige Subredes.
• Comprueba que el pod de aws-node esté en estado de ejecución. Además, asegúrate de utilizar la última versión compatible del CNI de Amazon VPC.
• Comprueba si la cantidad de pods de la instancia ha alcanzado la cantidad máxima de pods.
• En el nodo en el que programaste el pod, busca mensajes de error en los registros de ipamd y el complemento en la ruta var/log/aws-routed-eni.

Error de estado de CrashLoopBackOff

Aparece el mensaje de error «Back-Off restarting failed container».

El mensaje de error anterior se produce porque el contenedor no se inicia repetidamente y, a continuación, entra en el estado CrashLoopBackOff y se reinicia de forma persistente dentro del pod.

Los siguientes problemas pueden provocar que el contenedor no se inicie repetidamente:

• Memoria insuficiente
• Sobrecarga de recursos
• Errores de despliegue
• Problemas de dependencia externa, como errores de DNS
• Dependencias de terceros
• Errores a nivel de contenedor causados por conflictos de puertos

Para obtener los errores en los registros del pod actual, ejecuta el siguiente comando kubectl logs:

kubectl logs YOUR_POD_NAME -n YOUR_NAMESPACE

Nota: Sustituye YOUR_POD_NAME por el nombre de tu pod y YOUR_NAMESPACE por tu espacio de nombres.

Para obtener errores en los registros del pod anterior que se bloqueó, ejecuta el siguiente comando kubectl logs --previous:

kubectl logs --previous YOUR_POD_NAME -n YOUR_NAMESPACE

Nota: Sustituye YOUR_POD_NAME por el nombre de tu pod y YOUR_NAMESPACE por tu espacio de nombres.

Errores de sondeo

Cuando un pod se bloquea, aparece un error de sondeo debido a la denegación de la conexión o al tiempo de espera del cliente.

Solución de problemas de una conexión rechazada

Si se produce un error en un sondeo porque se ha rechazado la conexión, es posible que aparezca uno de los siguientes mensajes de error:

• «Liveness probe failed: Get https://$POD_IP:8080/<healthcheck_path>: dial tcp POD_IP:8080: connect: connection refused».
• «Readiness probe failed: Get https://$POD_IP:8080/<healthcheck_path>: dial tcp POD_IP:8080: connect: connection refused».

Para solucionar los problemas de una conexión rechazada, sigue estos pasos:

1. Para obtener manualmente la ruta de comprobación de estado definida en el manifiesto del pod desde el nodo de trabajo, ejecuta el siguiente comando:

   [ec2-user@ip-10-5-1-12 ~]$ curl -ikv podIP:8080//your_healthcheck_path

   Nota: Sustituye podIP por la dirección IP de tu pod y your_healthcheck_path por el nombre de tu ruta.

2. Comprueba la ruta de comprobación de estado definida en el manifiesto del pod para ver el pod que no pasó el sondeo de disponibilidad o el sondeo de preparación. Para comprobar la ruta de comprobación de estado, ejecuta el siguiente comando:

   local@bastion-host ~ % kubectl exec YOUR_POD_NAME -- curl -ikv "http://localhost:8080/your_healthcheck_path"

   Nota: Sustituye YOUR_POD_NAME por el nombre de tu pod.

3. Ejecuta la misma imagen de contenedor en el host bastión.

4. Comprueba si puedes obtener la ruta de comprobación de estado definida en los sondeos del manifiesto. A continuación, comprueba si hay fallos, tiempos de espera o errores en los registros del contenedor.

5. Para comprobar si hay errores en los registros de kubelet del nodo de trabajo en el que se ejecuta el pod, ejecuta el siguiente comando journalctl:

   [ec2-user@ip-10-5-1-12 ~]$ journalctl -u kubelet //optionally 'grep' with pod name

Solución de problemas de tiempo de espera de un cliente

Si se produce un error en un sondeo porque se agotó el tiempo de espera del cliente, es posible que aparezca uno de los siguientes mensajes de error:

• «Liveness probe failed: Get "http://podIP:8080/<healthcheck_path> ": context deadline exceeded (Client.Timeout exceeded while awaiting headers)».
• «Readiness probe failed: Get "http://podIP:8080/<healthcheck_path> ": context deadline exceeded (Client.Timeout exceeded while awaiting headers)».

Para solucionar problemas relacionados con el tiempo de espera del cliente, comprueba si la configuración es correcta para los sondeos de disponibilidad y los sondeos de preparación de los pods de aplicaciones.

Si usas un grupo de seguridad para los pods y ENABLE_POD_ENI=true, debes desactivar el demux temprano de TCP. Esta acción permite que el kubelet se conecte a los pods de las interfaces de red de ramificaciones que utilizan TCP.

Para desactivar el demux temprano deTCP, ejecuta el siguiente comando kubectl patch:

kubectl patch daemonset aws-node -n kube-system \-p '{"spec": {"template": {"spec": {"initContainers": [{"env":[{"name":"DISABLE_TCP_EARLY_DEMUX","value":"true"}],"name":"aws-vpc-cni-init"}]}}}}'

Error ImagePullBackOff

El error ImagePullBackOff se produce cuando un contenedor que se ejecuta en un pod no puede extraer la imagen requerida del registro de un contenedor.

Los siguientes problemas también provocan este error:

• Problemas de conectividad de red
• Nombre o etiqueta de imagen incorrectos
• Faltan credenciales
• Permisos insuficientes

Para determinar la causa del problema, sigue estos pasos:

1. Para averiguar el estado del pod, ejecuta el siguiente comando:

   kubectl get pods -n YOUR_NAMESPACE

   Nota: Sustituye YOUR_NAMESPACE por tu espacio de nombres.

2. Para obtener información sobre los errores de tu pod, ejecuta el siguiente comando:

   kubectl describe pod YOUR_POD_NAME -n YOUR_NAMESPACE

   Nota: Sustituye YOUR_POD_NAME por el nombre de tu pod y YOUR_NAMESPACE por tu espacio de nombres.

   Resultado de ejemplo:

   Events:
   Type     Reason     Age                From                Message
   ----     ------     ----               ----                -------
   Normal   Scheduled  18m                default-scheduler   Successfully assigned kube-system/kube-proxy-h4np6 to XXX.XXX.eu-west-1.compute.internal
   Normal   Pulling    16m (x4 over 18m)  kubelet             Pulling image "<account-id>.dkr.ecr.eu-west-1.amazonaws.com/eks/kube-proxy:v1.21.5-eksbuild.2"
   Warning  Failed     16m (x4 over 18m)  kubelet             Failed to pull image "<account-d>.dkr.ecr.eu-west-1.amazonaws.com/eks/kube-proxy:v1.21.5-eksbuild.2": rpc error: code = Unknown desc = Error response from daemon: manifest for <account-id>.dkr.ecr.eu-west-1.amazonaws.com/eks/kube-proxy:v1.21.5-eksbuild.2 not found: manifest unknown: Requested image not found

Para solucionar el error ImagePullBackOff, consulta ¿Cómo puedo solucionar los errores «ErriImagePull» e «ImagePullBackoff» del estado del pod en Amazon EKS?