Comparteix a través de

Solución de problemas de un cambio en un nodo correcto a Estado no preparado

  • Article

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 que se ejecutan) cambia inesperadamente a No preparado. Para ver el estado de un nodo, ejecute el siguiente comando kubectl describe :

kubectl describe nodes

Causa

El 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 según lo previsto? (Por ejemplo, en Campo Condiciones , ¿la message propiedad contiene la cadena "kubelet is posting 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 del demonio de contenedor y kubelet mediante la ejecución de los siguientes comandos de shell:

# To check messages file,
cat /var/log/messages

# To check kubelet and containerd daemon logs,
journalctl -u kubelet > kubelet.log
journalctl -u containerd > containerd.log

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

Solución

Paso 1: Comprobación de los cambios en el nivel de red

Si todos los nodos de clúster vuelven 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:

  • Cambios del sistema de nombres de dominio (DNS)
  • Cambia la regla de firewall, como el puerto, los nombres de dominio completos (FQDN), etc.
  • Grupos de seguridad de red (NSG) añadidos.
  • Configuraciones de tabla de rutas aplicadas o modificadas para el tráfico de AKS

Si se han producido cambios en el nivel de red, realice las correcciones necesarias. Si tiene acceso directo a Secure Shell (SSH) al nodo, puede usar el curl comando o telnet para comprobar la conectividad con los requisitos de salida de AKS. Después de corregir los problemas, detenga y reinicie los nodos. 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 unos pocos nodos vuelven a un estado No listo , basta con detener y reiniciar los nodos. Esta acción solo podría devolver los nodos a un estado correcto. A continuación, consulte Introducción al diagnóstico de Azure Kubernetes Service 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 y los nodos devueltos al estado Listo, 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 detectaron 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 dependen del 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 conectividad de salida. 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 tiene un comportamiento incorrecto. Use las métricas y los registros de Azure Monitor para apoyar sus conclusiones. Por ejemplo, puede usar la categoría Failed (Error ) como métrica conexiones SNAT.

  • Evalúe si se siguen los patrones adecuados.

  • Evalúe si el agotamiento de puertos SNAT debe mitigarse con más direcciones IP de salida y más puertos de salida 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.

Para obtener más información sobre cómo solucionar problemas de exhaución de puertos SNAT, consulte Solución de problemas de agotamiento de puertos SNAT en nodos de AKS.

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 conjuntos de escalado de máquinas virtuales (VM), elija un tamaño de disco mayor que ofrezca un mejor rendimiento de IOPS mediante la implementación de un nuevo grupo de nodos. No se admite el cambio de tamaño directo de VMSS directamente. Para más información sobre el cambio de tamaño de los grupos de nodos, consulte Cambio de tamaño de los grupos de nodos en Azure Kubernetes Service (AKS).

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

  • 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 de nodo y situaciones de memoria insuficiente.

  • Utilice 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: Corregir problemas de subproceso

Los componentes de Kubernetes, como kubelets y los 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 se reinicia mediante un corrector y es capaz de recuperarse.

  • En los archivos de registro /var/log/messages y /var/log/syslog , hay repeticiones repetidas de las siguientes entradas de error:

    Error pthread_create: recurso temporalmente no disponible por varios procesos

    Los procesos citados incluyen containerd y posiblemente kubelet.

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

Los id. de proceso (PID) representan subprocesos. El número predeterminado de PID que un pod puede utilizar puede depender del sistema operativo. Sin embargo, el número predeterminado es, al menos, 32 768. Esta cantidad de PID es más que suficiente para la mayoría de las situaciones. ¿Hay algún requisito de aplicación conocido para recursos de PID más altos? Si no lo hay, es posible que incluso un aumento de hasta ocho veces más (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. Considere 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 número de subprocesos de cada grupo de control (cgroup) e imprimir los ocho grupos 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 id. de proceso.

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

  1. Configure el número máximo de PID 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 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 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 más información, consulte el Acuerdo de Nivel de Servicio de tiempo de actividad de Azure Kubernetes Service (AKS).

Más información