Solución de problemas de estado no listo de un nodo en buen estado

  • Artículo

En este artículo se describe un escenario en el que el estado de un nodo de clúster de Azure Kubernetes Service (AKS) cambia a No listo después de que el nodo esté en un estado correcto durante algún tiempo. En este artículo se describe la causa concreta y se proporciona una posible solución.

Requisitos previos

Síntomas

El estado de un nodo de clúster que tiene un estado correcto (todos los servicios en ejecución) cambia inesperadamente a No listo. Para ver el estado de un nodo, ejecute el siguiente comando kubectl describe :

kubectl describe nodes

Causa

Kubelet dejó de publicar su estado Listo.

Examine la salida del kubectl describe nodes comando para buscar el campo Condiciones y los bloques Capacity y Allocatable . ¿El contenido de estos campos aparece como se esperaba? (Por ejemplo, en el campo Condiciones , ¿la message propiedad contiene la cadena "kubelet is post ready status"?) En este caso, si tiene acceso directo de Secure Shell (SSH) al nodo, compruebe los eventos recientes para comprender el error. Busque en el archivo /var/log/messages . O bien, genere los archivos de registro de kubelet y demonio de contenedor ejecutando los siguientes comandos de shell:

journalctl --directory=. --unit=kubelet > kubelet.log
journalctl --directory=. --unit=docker > docker.log

Después de ejecutar estos comandos, examine los archivos de registro del demonio para obtener más información sobre el error.

Paso 1: Comprobar si hay cambios en el nivel de red

Si todos los nodos del clúster retrocedieron a un estado No listo , compruebe si se han producido cambios en el nivel de red. Entre los ejemplos de cambios de nivel de red se incluyen los siguientes elementos:

  • Cambios en el sistema de nombres de dominio (DNS)
  • Cambios en el puerto de firewall
  • Se han agregado grupos de seguridad de red (NSG)

Si se produjeron cambios en el nivel de red, realice las correcciones necesarias. Detenga y reinicie los nodos que se ejecutan después de haber corregido los problemas. Si los nodos permanecen en un estado correcto después de estas correcciones, puede omitir de forma segura los pasos restantes.

Paso 2: Detener y reiniciar los nodos

Si solo algunos nodos retroceden a un estado No listo , basta con detener y reiniciar los nodos. Esta acción por sí sola puede devolver los nodos a un estado correcto. A continuación, compruebe Azure Kubernetes Service información general de diagnóstico para determinar si hay algún problema, como los siguientes:

  • Errores de nodo
  • Errores de traducción de direcciones de red de origen (SNAT)
  • Problemas de rendimiento de las operaciones de entrada y salida de nodo por segundo (IOPS)
  • Otros problemas

Si los diagnósticos no detectan ningún problema subyacente, puede omitir de forma segura los pasos restantes.

Paso 3: Corrección de problemas de SNAT para clústeres de API de AKS públicos

¿Los diagnósticos de AKS descubrieron algún problema de SNAT? Si es así, realice algunas de las siguientes acciones, según corresponda:

  • Compruebe si las conexiones permanecen inactivas durante mucho tiempo y confíe en el tiempo de espera de inactividad predeterminado para liberar su puerto. Si las conexiones muestran este comportamiento, es posible que tenga que reducir el tiempo de espera predeterminado de 30 minutos.

  • Determine cómo crea la aplicación la conectividad saliente. Por ejemplo, ¿usa la revisión de código o la captura de paquetes?

  • Determine si esta actividad representa el comportamiento esperado o, en su lugar, muestra que la aplicación se comporta mal. Use métricas y registros en Azure Monitor para fundamentar los resultados. Por ejemplo, puede usar la categoría Error como métrica de Connections SNAT.

  • Evalúe si se siguen los patrones adecuados.

  • Evalúe si debe mitigar el agotamiento de puertos SNAT mediante direcciones IP salientes adicionales y puertos de salida más asignados. Para obtener más información, consulte Escalado del número de direcciones IP públicas de salida administradas y Configuración de los puertos de salida asignados.

Paso 4: Corrección de problemas de rendimiento de IOPS

Si los diagnósticos de AKS detectan problemas que reducen el rendimiento de IOPS, realice algunas de las siguientes acciones, según corresponda:

  • Para aumentar las IOPS en los conjuntos de escalado de máquinas virtuales (VM), cambie el tamaño del disco mediante la implementación de un nuevo grupo de nodos.

  • Aumente el tamaño de la SKU del nodo para obtener más capacidad de procesamiento de cpu y memoria.

  • Considere la posibilidad de usar el sistema operativo efímero.

  • Limite el uso de CPU y memoria para pods. Estos límites ayudan a evitar el consumo de CPU del nodo y las situaciones de memoria insuficiente.

  • Use métodos de topología de programación para agregar más nodos y distribuir la carga entre los nodos. Para obtener más información, consulte Restricciones de propagación de topología de pod.

Paso 5: Corrección de problemas de subprocesos

Los componentes de Kubernetes, como kubelets y entornos de ejecución en contenedores , dependen en gran medida del subproceso y generan nuevos subprocesos con regularidad. Si la asignación de nuevos subprocesos no se realiza correctamente, este error puede afectar a la preparación del servicio, como se indica a continuación:

  • El estado del nodo cambia a No listo, pero lo reinicia un corrector y es capaz de recuperarlo.

  • En los archivos de registro /var/log/messages y /var/log/syslog , se repiten las siguientes entradas de error:

    error de pthread_create: los recursos no están disponibles temporalmente por varios procesos

    Los procesos que se citan incluyen contenedor y posiblemente kubelet.

  • El estado del nodo cambia a No listo poco después de que las pthread_create entradas de error se escriban en los archivos de registro.

Los identificadores de proceso (PID) representan subprocesos. El número predeterminado de PIN que puede usar un pod puede depender del sistema operativo. Sin embargo, el número predeterminado es al menos 32 768. Esta cantidad es más que suficiente para la mayoría de las situaciones. ¿Existen requisitos de aplicación conocidos para recursos de PID más altos? Si no lo hay, es posible que incluso un aumento de ocho veces a 262 144 PID no sea suficiente para dar cabida a una aplicación de recursos elevados.

En su lugar, identifique la aplicación infractora y, a continuación, realice la acción adecuada. Tenga en cuenta otras opciones, como aumentar el tamaño de la máquina virtual o actualizar AKS. Estas acciones pueden mitigar el problema temporalmente, pero no son una garantía de que el problema no vuelva a aparecer.

Para supervisar el recuento de subprocesos para cada grupo de control (cgroup) e imprimir los ocho grupos de c principales, ejecute el siguiente comando de shell:

watch 'ps -e -w -o "thcount,cgname" --no-headers | awk "{a[\$2] += \$1} END{for (i in a) print a[i], i}" | sort --numeric-sort --reverse | head --lines=8'

Para obtener más información, consulte Límites y reservas de identificadores de proceso.

Kubernetes ofrece dos métodos para administrar el agotamiento del PID en el nivel de nodo:

  1. Configure el número máximo de PIN que se permiten en un pod dentro de un kubelet mediante el --pod-max-pids parámetro . Esta configuración establece la pids.max configuración dentro del grupo de c de cada pod. También puede usar los --system-reserved parámetros y --kube-reserved para configurar los límites del sistema y kubelet, respectivamente.

  2. Configure la expulsión basada en PID.

Nota:

De forma predeterminada, ninguno de estos métodos está configurado. Además, actualmente no puede configurar ninguno de los métodos mediante la configuración de Node para los grupos de nodos de AKS.

Paso 6: Uso de un nivel de servicio superior

Puede asegurarse de que el servidor de API de AKS tiene alta disponibilidad mediante un nivel de servicio superior. Para obtener más información, consulte el acuerdo de nivel de servicio de tiempo de actividad de Azure Kubernetes Service (AKS).

Más información