Agente de supervisión de nodos Reparación automática de nodos Problemas de estado de los nodos

Cómo habilitar la reparación automática de los nodos e investigar los problemas de estado de los nodos

El estado del nodo hace referencia a su funcionamiento operativo y a su capacidad para ejecutar cargas de trabajo de manera eficiente. Un nodo en buen estado mantiene la conectividad esperada, cuenta con recursos suficientes y puede ejecutar los pods correctamente sin interrupciones. Para obtener información sobre cómo obtener detalles sobre los nodos, consulte Cómo ver el estado de los nodos y Recuperación de los registros de nodos de un nodo administrado mediante kubectl y S3.

Para ayudar a mantener nodos en buen estado, Amazon EKS ofrece el agente de supervisión de nodos y la reparación automática de nodos.

importante

El agente de supervisión de nodos y la reparación automática de nodos solo están disponibles en Linux. Estas características no están disponibles en Windows.

Agente de supervisión de nodos

El agente de supervisión de nodos lee automáticamente los registros de los nodos para detectar ciertos problemas de estado. Analiza los registros de los nodos para detectar fallas y muestra diversa información de estado sobre los nodos de trabajo. Se aplica una NodeCondition específica a los nodos de trabajo para cada categoría de problemas detectados, como los relacionados con almacenamiento o redes. Las descripciones de los problemas de estado detectados están disponibles en el panel de observabilidad. Para obtener más información, consulte Problemas de estado de los nodos.

El agente de supervisión de nodos se incluye como una capacidad para todos los clústeres del modo automático de Amazon EKS. Para otros tipos de clústeres, puede agregar el agente de supervisión como complemento de Amazon EKS. Para obtener más información, consulte Cómo crear un complemento de Amazon EKS.

Reparación automática de nodos

La reparación automática de nodos es una característica adicional que supervisa continuamente el estado de los nodos, reacciona automáticamente a los problemas detectados y reemplaza los nodos cuando es posible. Esto contribuye a mantener la disponibilidad general del clúster con una intervención manual mínima. Si se produce un error en una comprobación de estado, el nodo se acordona automáticamente para que no se programen nuevos pods en este.

Por sí sola, la reparación automática de nodos puede reaccionar ante la condición Ready del kubelet y cualquier objeto de nodo que sea eliminado manualmente. Cuando se combina con el agente de supervisión de nodos, la reparación automática de nodos puede reaccionar ante más condiciones que de otro modo no se detectarían. Algunas de estas condiciones adicionales son KernelReady, NetworkingReady y StorageReady.

Esta recuperación automatizada de nodos aborda automáticamente problemas intermitentes de los nodos, como fallos al unirse al clúster, kubelets no receptivos y un aumento en los errores de aceleradores (dispositivos). La confiabilidad mejorada ayuda a reducir el tiempo de inactividad de las aplicaciones y a mejorar las operaciones del clúster. La reparación automática de nodos no puede solucionar ciertos problemas que se reportan, como DiskPressure, MemoryPressure y PIDPressure. Amazon EKS espera 10 minutos antes de actuar sobre las NodeConditions AcceleratedHardwareReady y 30 minutos para todas las demás condiciones.

Los grupos de nodos administrados también desactivarán automáticamente las reparaciones de nodos por motivos de seguridad en dos circunstancias. Cualquier operación de reparación que ya esté en curso continuará en ambas circunstancias.

Si el controlador de recuperación de aplicaciones (ARC) ha provocado un cambio de zona en el clúster, se detendrán todas las operaciones de reparación posteriores.
Si el grupo de nodos tiene más de cinco nodos y más del 20 % de los nodos del grupo de nodos están en mal estado, se detendrán las operaciones de reparación.

Puede habilitar la reparación automática de nodos al crear o editar un grupo de nodos administrado.

Cuando utilice la consola Amazon EKS, active la casilla de verificación Habilitar la reparación automática de nodos para el grupo de nodos administrado. Para obtener más información, consulte Creación de un grupo de nodos administrados para un clúster.
Al utilizar la AWS CLI, agregue --node-repair-config enabled=true al comando eks create nodegroup o eks update-nodegroup-config.
Para una ClusterConfig de eksctl que usa un grupo de nodos administrado con reparación automática de nodos, consulte 44-node-repair.yaml en GitHub.

Amazon EKS proporciona un control más detallado sobre el comportamiento de reparación automática de nodos mediante lo siguiente:

maxUnhealthyNodeThresholdCount y maxUnhealthyNodeThresholdPercentage
- Estos campos le permiten especificar un umbral de recuento o porcentaje de nodos en mal estado, por encima del cual se detendrán las acciones de reparación automática de nodos. De este modo, se proporciona un mayor control sobre el “radio de acción” de las reparaciones automáticas de nodos.
- Puede establecer el porcentaje o el recuento absoluto, pero no ambos
maxParallelNodesRepairedCount y maxParallelNodesRepairedPercentage
- Estos campos le permiten especificar el número máximo de nodos que se pueden reparar simultáneamente o en paralelo, expresado como un recuento o un porcentaje de todos los nodos en mal estado. Esto le permite controlar con mayor precisión el ritmo de las sustituciones de nodos.
- Al igual que con el umbral de nodos en mal estado, puede establecer el porcentaje o el recuento absoluto, pero no ambos.
nodeRepairConfigOverrides
- Se trata de una estructura compleja que permite establecer anulaciones detalladas para acciones de reparación específicas. Estas anulaciones controlan la acción de reparación y el tiempo de demora de la reparación antes de que un nodo se considere elegible para la reparación.
- Los campos específicos de esta estructura son:
  - nodeMonitoringCondition: la condición en mal estado notificada por el agente de supervisión de nodos.
  - nodeUnhealthyReason: el motivo por el que el agente de supervisión de nodos identificó el nodo como en mal estado.
  - minRepairWaitTimeMins: el tiempo mínimo (en minutos) que deben persistir la condición de reparación y el motivo de mal estado antes de que el nodo sea elegible para la reparación.
  - repairAction: la acción que debe llevar a cabo el sistema de reparación cuando se cumplen las condiciones anteriores.
- Si utiliza este campo, debe especificar todos los campos de la estructura. También puede proporcionar una lista de estas anulaciones.
- nodeMonitoringCondition y nodeUnhealthyReason son entradas de texto manuales que se configuran para indicar que se quiere desviar del comportamiento predeterminado del sistema.
- Los campos minRepairWaitTimeMins y repairAction permiten especificar las desviaciones del comportamiento predeterminado del sistema.

Problemas de estado de los nodos

En las siguientes tablas se describen los problemas de estado de los nodos que el agente de supervisión de nodos puede detectar. Existen dos tipos de problemas:

Condición: un problema terminal que requiere una acción correctiva, como la sustitución o el reinicio de la instancia. Cuando la reparación automática está habilitada, Amazon EKS realizará una acción de reparación, ya sea la sustitución o el reinicio del nodo. Para obtener más información, consulte Condiciones de nodos.
Evento: un problema temporal o una configuración de nodo subóptima. No se realizará ninguna acción de reparación automática. Para obtener más información, consulte Eventos de nodos.

Problemas de estado de los nodos AcceleratedHardware

La condición de supervisión es AcceleratedHardwareReady para los problemas de la tabla siguiente que tengan una gravedad de “Estado”.

Si la reparación automática está habilitada, las acciones de reparación que aparecen en la lista comenzarán 10 minutos tras la detección del problema. Para obtener más información sobre los errores de XID, consulte Errores de Xid en la documentación sobre la implementación y administración de las GPU de NVIDIA. Para obtener más información sobre los mensajes XID individuales, consulte Comprensión de los mensajes Xid en la documentación sobre implementación y administración de GPU de NVIDIA.

Nombre	Gravedad	Descripción
DCGMDiagnosticFailure	Condición	Se produjo un error en un caso de prueba del conjunto de pruebas de diagnóstico activo de DCGM.
DCGMError	Condición	Se perdió la conexión con el proceso host del DCGM o no fue posible establecerla.
DCGMFieldError[Código]	Evento	El DCGM detectó la degradación de la GPU a través de un identificador de campo.
DCGMHealthCode[Código]	Evento	Una comprobación de estado del DCGM falló de manera no fatal.
DCGMHealthCode[Código]	Condición	Una comprobación de estado del DCGM falló de manera fatal.
NeuronDMAError	Condición	Un motor de DMA encontró un error no recuperable.
NeuronHBMUncorrectableError	Condición	Un HBM encontró un error no corregible y generó resultados incorrectos.
NeuronNCUncorrectableError	Condición	Se detectó un error de memoria incorregible en Neuron Core.
NeuronSRAMUncorrectableError	Condición	Una SRAM integrada en el chip encontró un error de paridad y generó resultados incorrectos.
NvidiaDeviceCountMismatch	Evento	La cantidad de GPU visibles a través de NVML no coincide con el número de dispositivos de NVIDIA del sistema de archivos.
NvidiaDoubleBitError	Condición	El controlador de la GPU produjo un error de doble bit.
NvidiaNCCLError	Evento	Se ha producido un error segfault en NVIDIA Collective Communications Library (`libnccl`).
NvidiaNVLinkError	Condición	El controlador de la GPU notificó errores de NVLink.
NvidiaPCIeError	Evento	Las repeticiones de PCIe se activaron para recuperarse de errores de transmisión.
NvidiaPageRetirement	Evento	El controlador de la GPU ha marcado una página de memoria para su retirada. Esto puede ocurrir si hay un único error de doble bit o si se encuentran dos errores de bit único en la misma dirección.
NvidiaPowerError	Evento	El uso de energía de las GPU superó los umbrales permitidos.
NvidiaThermalError	Evento	El estado térmico de las GPU superó los umbrales permitidos.
NvidiaXID[Código]Error	Condición	Se ha producido un error crítico de la GPU.
NvidiaXID[Code]Warning	Evento	Se ha producido un error no crítico de la GPU.

Problemas de estado de los nodos ContainerRuntime

La condición de supervisión es ContainerRuntimeReady para los problemas de la tabla siguiente que tengan una gravedad de “Estado”.

Nombre	Gravedad	Descripción
ContainerRuntimeFailed	Evento	El tiempo de ejecución del contenedor no pudo crear un contenedor, lo que probablemente está relacionado con cualquier problema reportado si ocurre de manera repetida.
DeprecatedContainerdConfiguration	Evento	Recientemente, se incorporó al nodo a través de `containerd` una imagen de contenedor con un manifiesto de imagen obsoleto (versión 2, esquema 1).
KubeletFailed	Evento	El kubelet entró en un estado de fallo.
LivenessProbeFailures	Evento	Se detectó una falla en la sonda de actividad, lo que podría indicar problemas en el código de la aplicación o valores de tiempo de espera insuficientes si ocurre de manera repetida.
PodStuckTerminating	Condición	Un pod está o estuvo atascado al intentar terminar durante un tiempo excesivo, lo que puede ser causado por errores en CRI que impiden la progresión del estado del pod.
ReadinessProbeFailures	Evento	Se detectó una falla en la sonda de preparación, lo que podría indicar problemas en el código de la aplicación o valores de tiempo de espera insuficientes si ocurre de manera repetida.
[Nombre]RepeatedRestart	Evento	Una unidad systemd se reinicia con frecuencia.
ServiceFailedToStart	Evento	No se pudo iniciar una unidad de systemd.

Problemas de estado de los nodos del núcleo

La condición de supervisión es KernelReady para los problemas de la tabla siguiente que tengan una gravedad de “Estado”.

Nombre	Gravedad	Descripción
AppBlocked	Evento	La tarea ha estado bloqueada durante un largo período para su programación, generalmente debido a estar bloqueada en la entrada o salida.
AppCrash	Evento	Se colapsó una aplicación del nodo.
ApproachingKernelPidMax	Evento	La cantidad de procesos está próxima a alcanzar la cantidad máxima de PID disponibles según la configuración de `kernel.pid_max` actual. Una vez alcanzado este límite, no se podrán inicializar más procesos.
ApproachingMaxOpenFiles	Evento	La cantidad de archivos abiertos está próxima a la cantidad máxima de archivos abiertos posibles dada la configuración actual del núcleo. Una vez alcanzado este límite, no se podrán abrir nuevos archivos.
ConntrackExceededKernel	Evento	El seguimiento de conexiones excedió el límite máximo del núcleo, lo que impidió el establecimiento de nuevas conexiones y podría ocasionar la pérdida de paquetes.
ExcessiveZombieProcesses	Evento	Los procesos que no pueden ser completamente recuperados se acumulan en grandes cantidades, lo que indica problemas en la aplicación y podría llevar a alcanzar los límites de procesos del sistema.
ForkFailedOutOfPIDs	Condición	Una llamada a fork o exec ha fallado debido a que el sistema se ha quedado sin identificadores de proceso o memoria, lo cual podría ser causado por procesos zombis o agotamiento de la memoria física.
KernelBug	Evento	Se detectó un error en el núcleo y fue reportado por el propio núcleo de Linux, aunque esto a veces puede ser causado por nodos con un alto uso de CPU o memoria que provocan retrasos en el procesamiento de eventos.
LargeEnvironment	Evento	La cantidad de variables de entorno de este proceso es mayor de lo esperado, lo que se podría deber a la existencia de muchos servicios con `enableServiceLinks` configurado en verdadero, lo que podría provocar problemas de rendimiento.
RapidCron	Evento	Un trabajo cron se ejecuta con una frecuencia inferior a cinco minutos en este nodo, lo que podría afectar el rendimiento si el trabajo consume recursos significativos.
SoftLockup	Evento	La CPU se detuvo durante un periodo determinado.

Problemas de estado de los nodos de red

La condición de supervisión es NetworkingReady para los problemas de la tabla siguiente que tengan una gravedad de “Estado”.

Nombre	Gravedad	Descripción
BandwidthInExceeded	Evento	Los paquetes se han puesto en cola o se han descartado porque el ancho de banda agregado de entrada ha superado el máximo para la instancia.
BandwidthOutExceeded	Evento	Los paquetes se han puesto en cola o se han descartado porque el ancho de banda agregado de salida ha superado el máximo para la instancia.
ConntrackExceeded	Evento	El seguimiento de conexiones excedió el límite máximo de la instancia, lo que impidió el establecimiento de nuevas conexiones, lo que podría ocasionar la pérdida de paquetes.
IPAMDInconsistentState	Evento	El estado del punto de control de IPAMD en el disco no refleja las IP en el tiempo de ejecución del contenedor.
IPAMDNoIPs	Evento	IPAMD se quedó sin direcciones IP.
IPAMDNotReady	Condición	IPAMD no se puede conectar al servidor de la API.
IPAMDNotRunning	Condición	El proceso de CNI de Amazon VPC no se encontró en ejecución.
IPAMDRepeatedlyRestart	Evento	Se han producido múltiples reinicios en el servicio IPAMD.
InterfaceNotRunning	Condición	Esta interfaz parece no estar en ejecución o existen problemas de red.
InterfaceNotUp	Condición	Parece que esta interfaz no está activa o que existen problemas de red.
KubeProxyNotReady	Evento	Kube-proxy no pudo ver ni enumerar los recursos.
LinkLocalExceeded	Evento	Se descartaron paquetes porque los paquetes por segundo (PPS) del tráfico hacia los servicios proxy locales excedieron el máximo de la interfaz de red.
MACAddressPolicyMisconfigured	Evento	La configuración del enlace systemd-networkd tiene un valor `MACAddressPolicy` incorrecto.
MissingDefaultRoutes	Evento	Faltan reglas de ruta predeterminadas.
MissingIPRoutes	Evento	Faltan rutas para las IP de los pods.
MissingIPRules	Evento	Faltan reglas para las IP de los pods.
MissingLoopbackInterface	Condición	La interfaz de bucle de retorno falta en esta instancia, lo que provoca fallos en los servicios que dependen de la conectividad local.
NetworkSysctl	Evento	La configuración de `sysctl` de red de este nodo es potencialmente incorrecta.
PPSExceeded	Evento	Los paquetes han sido puestos en cola o descartados porque los paquetes por segundo (PPS) bidireccionales excedieron el máximo permitido para la instancia.
PortConflict	Evento	Si un pod utiliza hostPort, puede escribir reglas de `iptables` que sobrescriban los puertos ya asignados del host, lo que podría impedir el acceso del servidor de la API al `kubelet`.
UnexpectedRejectRule	Evento	Se encontró una regla inesperada de `REJECT` o `DROP` en las `iptables`, lo que podría bloquear el tráfico esperado.

Problemas de estado en el nodo de almacenamiento

La condición de supervisión es StorageReady para los problemas de la tabla siguiente que tengan una gravedad de “Estado”.

Nombre	Gravedad	Descripción
EBSInstanceIOPSExceeded	Evento	Se ha superado el máximo de IOPS de la instancia.
EBSInstanceThroughputExceeded	Evento	Se ha superado el rendimiento máximo de la instancia.
EBSVolumeIOPSExceeded	Evento	Se ha superado el máximo de IOPS para un volumen de EBS concreto.
EBSVolumeThroughputExceeded	Evento	Se ha superado el rendimiento máximo de un volumen de Amazon EBS concreto.
EtcHostsMountFailed	Evento	El montaje del `/etc/hosts` generado por el kubelet falló debido al remonte de `/var/lib/kubelet/pods` por parte de userdata durante la operación del `kubelet-container`.
IODelays	Evento	Se detectó un retraso en la entrada o salida de un proceso, lo que podría indicar un aprovisionamiento insuficiente de recursos de entrada y salida si es excesivo.
KubeletDiskUsageSlow	Evento	El `kubelet` informa de un uso lento del disco al intentar acceder al sistema de archivos. Esto podría indicar que no hay suficientes entradas y salidas en el disco o problemas con el sistema de archivos.
XFSSmallAverageClusterSize	Evento	El tamaño medio del clúster de XFS es pequeño, lo que indica una fragmentación excesiva del espacio libre. De este modo, se puede impedir la creación de archivos a pesar de que haya nodos de indexación o espacio libre disponibles.

Aviso JavaScript está desactivado o no está disponible en su navegador.

Para utilizar la documentación de AWS, debe estar habilitado JavaScript. Para obtener más información, consulte las páginas de ayuda de su navegador.

Convenciones del documento

Compilaciones personalizadas

Cómo ver el estado de los nodos