¿Cómo soluciono los problemas de mi nodo de trabajo de Amazon EKS que pasa al estado NotReady debido a problemas con el PLEG?

6 minutos de lectura
0

Mis nodos de trabajo de Amazon Elastic Kubernetes Service (Amazon EKS) pasan al estado NotReady o Unknown porque el generador de eventos del ciclo de vida del pod (PLEG) no está en buen estado.

Resolución

Cuando los nodos de trabajo de su clúster de Amazon EKS pasan al estado NotReady o Unknown, las cargas de trabajo programadas en ese nodo se interrumpen. Para solucionar este problema, haga lo siguiente:

Para obtener información sobre el nodo de trabajo, ejecute el siguiente comando:

$ kubectl describe node node-name

En el resultado, consulte la sección Conditions (Condiciones) para encontrar la causa del problema.

Ejemplo:

KubeletNotReady  PLEG is not healthy: pleg was last seen active xx

Los motivos más comunes por los que el PLEG no se encuentra en buen estado son los siguientes:

  • Kubelet no puede comunicarse con el daemon de Docker porque el daemon está ocupado o inactivo. Por ejemplo, es posible que el daemon de Docker de su nodo de trabajo de EKS esté roto.
  • Un problema de falta de memoria (OOM) o de utilización de la CPU a nivel de instancia provocó que el PLEG dejara de funcionar.
  • Si el nodo de trabajo tiene una gran cantidad de pods, los daemon kubelet y Docker podrían experimentar cargas de trabajo más altas y provocar errores relacionados con el PLEG. También se pueden producir cargas de trabajo más altas si la actividad o la disponibilidad se controlan con frecuencia.

Comprobar los registros de kubelet

Puede comprobar los registros de kubelet de la instancia para identificar por qué PLEG no está en buen estado.

1.    Use SSH para conectarse a la instancia y ejecute el siguiente comando:

$ journalctl -u kubelet > kubelet.log

Si utiliza la AMI optimizada para Amazon EKS y SSH no está habilitado, puede conectarse mediante SSM. Para obtener más información, consulte Conectarse a la instancia de Linux mediante el Administrador de sesiones.

2.    Compruebe si hay eventos relacionados con PLEG publicados por kubelet en estos registros:

Ejemplo:

28317 kubelet.go:1873] "Skipping pod synchronization" err="PLEG is not healthy: pleg was last seen active 4h5m43.659028227s ago; threshold is 3m0s"
28317 kubelet.go:1873] "Skipping pod synchronization" err="PLEG is not healthy: pleg was last seen active 4h5m48.659213288s ago; threshold is 3m0s"

3.    Consulte los registros de kubelet para ver si hay algún pod que no esté funcionando en los sensores de preparación y actividad. Estos mensajes de registro tienen un aspecto similar al siguiente:

"Probe failed" probeType="Liveness" pod="nginx/bus" podUID=2527afb7-b32c-4c84-97e2-246eb48c97a9 containerName="nginx" probeResult=failure output="Get \"http://192.168.154.18:15020/app-health/livez\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)"

Utilice estos registros para identificar los pods que fallan. En el caso de los pods identificados, compruebe y asegúrese de que los sensores de estado estén configurados correctamente.

Monitorear el uso de los recursos del nodo de trabajo

Compruebe si hay algún problema a nivel de instancia, como escasez de recursos debido a problemas de OOM o a un uso elevado de la CPU.

Monitoree la métrica de utilización de la CPU del nodo de trabajo subyacente de Amazon Elastic Compute Cloud (Amazon EC2). Compruebe esta métrica para ver si hay picos repentinos o si la utilización de la CPU alcanza el 100 %.

Kubelet informa que el nodo está bajo presión cuando alcanza los umbrales de expulsión estrictos o flexibles, independientemente de los periodos de gracia configurados. Puede comprobar el estado del nodo al ejecutar el siguiente comando:

$ kubectl describe node <node_name>

Compruebe si la condición del nodo se indica como MemoryPressure en la salida. En estos casos, la instancia podría bloquearse debido a la falta de disponibilidad de recursos. Esto podría provocar que el proceso deje de responder.

Para mitigar los problemas ocasionados por la escasez de recursos, se recomienda establecer límites de uso de la CPU y la memoria para los pods.

Cuando especifique un límite de recursos para su contenedor, kubelet aplica estos límites. No se permite que el uso del contenedor en ejecución supere estos límites. Esto evita que el pod ocupe más memoria de la necesaria y, por lo tanto, se evitan problemas de OOM. Para obtener más información, consulte Administración de recursos para pods y contenedores en el sitio web de Kubernetes.

Además, considere la posibilidad de utilizar Container Insights para recopilar, agregar y resumir las métricas y los registros de sus aplicaciones y microservicios en contenedores. Para obtener más información, consulte las métricas de Amazon EKS y Kubernetes Container Insights. Puede usar node_cpu_utilization y node_memory_utilization para monitorear la utilización de los recursos a nivel del nodo. También puede configurar alarmas para recibir notificaciones cuando se alcance un determinado umbral.

Monitorear el rendimiento del volumen raíz de Amazon EBS

Es posible que el PLEG no esté en buen estado debido a problemas de disco en su volumen de Amazon Elastic Block Store (Amazon EBS). En este caso, los registros de kubelet tienen un aspecto similar al siguiente:

fs: disk usage and inodes count on following dirs took 1.262610491s: [/var/lib/docker/overlay2/709e904d843733d746e5134e55e3c6553db4c0f5297d5e3c3a86c206bcb6b172/diff /var/lib/docker/containers/158725d2d97578713034c5f5c16291a068349b7e989b417324c142bb584f79ad]; will not log again for this container unless duration exceeds 2s

Esto ocurre cuando las aplicaciones que utilizan los pods de la instancia realizan grandes cantidades de operaciones de E/S en el disco.

Puede monitorear la utilización y el rendimiento de las IOPS de su volumen de Amazon EBS mediante las métricas de Amazon CloudWatch para Amazon EBS.

Utilice las siguientes métricas de CloudWatch para monitorear el rendimiento y las IOPS de un volumen de Amazon EBS:

  • VolumeReadOps
  • VolumeWriteOps
  • VolumeReadBytes

Por ejemplo, puede calcular el promedio de IOPS en operaciones por segundo por medio de la siguiente fórmula:

((VolumeReadOps) + (VolumeWriteOps))/(Periodo)

Puede calcular el rendimiento promedio en bytes por segundo por medio de la siguiente fórmula:

((VolumeReadBytes) + (VolumeWriteBytes))/(Periodo)

Para obtener más información, consulte ¿Cómo puedo utilizar las métricas de CloudWatch para calcular el rendimiento y promedio de IOPS que provee mi volumen de EBS?

Para resolver este problema, considere aumentar el tamaño del disco o cambiar el tipo de volumen de EBS para lograr un mejor rendimiento de E/S.


OFICIAL DE AWS
OFICIAL DE AWSActualizada hace un año