**Ayude a mejorar esta página**
Para contribuir a esta guía del usuario, elija el enlace **Edit this page on GitHub** que se encuentra en el panel derecho de cada página.
# Detección de los problemas de estado de los nodos y reparación automática de los nodos
El estado del nodo hace referencia a su funcionamiento operativo y a la capacidad de un nodo de Kubernetes para ejecutar cargas de trabajo de manera eficiente. Un nodo en buen estado mantiene la conectividad esperada, cuenta con suficientes recursos informáticos y de almacenamiento y puede ejecutar las cargas de trabajo correctamente sin interrupciones.
Para ayudar a mantener nodos en buen estado en los clústeres de EKS, EKS ofrece el *agente de supervisión de nodos* y la *reparación automática de nodos*. Estas características se activan automáticamente con la computación en modo automático de EKS. También puede utilizar la reparación automática de nodos con grupos de nodos administrados por EKS y Karpenter, y puede utilizar el agente de supervisión de nodos de EKS con cualquier tipo de computación de EKS, excepto AWS Fargate. El agente de supervisión de nodos de EKS y la reparación automática de nodos son más eficaces cuando se utilizan juntos, pero también se pueden utilizar de forma individual en los clústeres de EKS.
**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 de EKS lee los registros de los nodos para detectar problemas de estado. Analiza los registros para detectar fallas y muestra información de estado sobre el estado de los nodos. Para cada categoría de problemas detectados, el agente aplica un `NodeCondition` dedicado a los nodos de trabajo. Para obtener información detallada sobre los problemas de estado de los nodos detectados por el agente de supervisión de nodos de EKS, consulte [Detecte problemas de estado de los nodos con el agente de supervisión de nodos EKS](node-health-nma.md).
La computación en modo automático de EKS incluye el agente de supervisión de nodos. Para otros tipos de computación de EKS, puede agregar el agente de supervisión de nodos como complemento de EKS o puede administrarlo con herramientas de Kubernetes como Helm. Para obtener más información, consulte [Configuración del agente de supervisión de nodos](node-health-nma.md#node-monitoring-agent-configure).
Con el agente de supervisión de nodos de EKS, las siguientes categorías de problemas de estado de los nodos aparecen como condiciones de los nodos. Tenga en cuenta que `Ready`, `DiskPressure` y `MemoryPressure` son condiciones estándar de los nodos de Kubernetes que aparecen incluso sin el agente de supervisión de nodos de EKS.
| Condiciones de nodos | Descripción |
| --- | --- |
| AcceleratedHardwareReady | AcceleratedHardwareReady indica si el hardware acelerado (GPU, Neuron) del nodo funciona correctamente. |
| ContainerRuntimeReady | ContainerRuntimeReady indica si el tiempo de ejecución del contenedor (containerd, etc.) funciona correctamente y puede ejecutar contenedores. |
| DiskPressure | DiskPressure es una condición estándar de Kubernetes que indica que el nodo está bajo presión en el disco (poco espacio en disco o gran cantidad de E/S). |
| KernelReady | KernelReady indica si el kernel funciona correctamente sin errores críticos, problemas o agotamiento de los recursos. |
| Presión de memoria | MemoryPressure es una condición estándar de Kubernetes que indica que el nodo está experimentando una presión de memoria (poca memoria disponible). |
| NetworkingReady | NetworkingReady indica si la pila de redes del nodo funciona correctamente (interfaces, enrutamiento, conectividad). |
| StorageReady | StorageReady indica si el subsistema de almacenamiento del nodo funciona correctamente (discos, sistemas de archivos, E/S). |
| Ready | Listo es la condición estándar de Kubernetes que indica que el nodo está en buen estado y listo para aceptar pods. |
## Reparación automática de nodos
La reparación automática de nodos de EKS supervisa continuamente el estado de los nodos, reacciona ante los problemas detectados y reemplaza o reinicia los nodos cuando es posible. Esto mejora la fiabilidad del clúster con una intervención manual mínima y ayuda a reducir el tiempo de inactividad de las aplicaciones.
Por sí sola, la reparación automática de nodos de EKS reacciona a las condiciones `Ready` del kubelet, a cualquier objeto de nodo eliminado manualmente y a las instancias de grupos de nodos administradas por EKS que no se unen al clúster. Cuando la reparación automática de nodos de EKS está habilitada con el agente de supervisión de nodos instalado, la reparación automática de nodos de EKS reacciona ante condiciones adicionales de los nodos: `AcceleratedHardwareReady`, `ContainerRuntimeReady`, `KernelReady`, `NetworkingReady` y `StorageReady`.
La reparación automática de nodos de EKS no reacciona a las condiciones de nodos `DiskPressure`, `MemoryPressure` o `PIDPressure` estándar de Kubernetes. Estas condiciones suelen indicar problemas relacionados con el comportamiento de la aplicación, la configuración de la carga de trabajo o los límites de recursos, en lugar de fallos en el nodo, lo que dificulta determinar una acción de reparación predeterminada adecuada. En estos escenarios, las cargas de trabajo están sujetas al [comportamiento de desalojo por presión de los nodos](https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction) de Kubernetes.
Para obtener más información sobre la reparación automática de nodos de EKS, consulte [Reparación automática de nodos en clústeres de EKS](node-repair.md).
**Topics**
# Detecte problemas de estado de los nodos con el agente de supervisión de nodos EKS
En este tema se detallan los problemas de estado de los nodos detectados por el agente de supervisión de nodos de EKS, cómo estos problemas se manifiestan como condiciones o eventos de los nodos y cómo configurar el agente de supervisión de nodos.
El agente de supervisión de nodos de EKS se puede utilizar con o sin la reparación automática de nodos de EKS. Para obtener más información sobre la reparación automática de nodos de EKS, consulte [Reparación automática de nodos en clústeres de EKS](node-repair.md).
El código fuente del agente de supervisión de nodos EKS está publicado en GitHub en el repositorio [aws/eks-node-monitoring-agent](https://github.com/aws/eks-node-monitoring-agent).
## 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](learn-status-conditions.md#status-node-conditions).
+ 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](learn-status-conditions.md#status-node-events).
## 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”. Los eventos y condiciones de la siguiente tabla se refieren a problemas de estado de los nodos relacionados con NVIDIA y Neuron.
| Nombre | Gravedad | Descripción | Acción de reparación |
| --- | --- | --- | --- |
| DCGMDiagnosticFailure | Condición | Se produjo un error en un caso de prueba del conjunto de pruebas de diagnóstico activo de DCGM. | Ninguno |
| DCGMError | Condición | Se perdió la conexión con el proceso host del DCGM o no fue posible establecerla. | Ninguno |
| DCGMFieldError[Código] | Evento | DCGM detectó degradación de la GPU mediante un identificador de campo. | Ninguno |
| DCGMHealthCode[Código] | Evento | Una comprobación de estado del DCGM falló de manera no fatal. | Ninguno |
| DCGMHealthCode[Código] | Condición | Una comprobación de estado del DCGM falló de manera fatal. | Ninguno |
| NeuronDMAError | Condición | Un motor de DMA encontró un error no recuperable. | Reemplazar |
| NeuronHBMUncorrectableError | Condición | Un HBM encontró un error no corregible y generó resultados incorrectos. | Reemplazar |
| NeuronNCUncorrectableError | Condición | Se detectó un error de memoria incorregible en Neuron Core. | Reemplazar |
| NeuronSRAMUncorrectableError | Condición | Una SRAM integrada en el chip encontró un error de paridad y generó resultados incorrectos. | Reemplazar |
| 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. | Ninguno |
| NvidiaDoubleBitError | Condición | El controlador de la GPU produjo un error de doble bit. | Reemplazar |
| NvidiaNCCLError | Evento | Se ha producido un error segfault en NVIDIA Collective Communications Library (`libnccl`). | Ninguno |
| NvidiaNVLinkError | Condición | El controlador de la GPU notificó errores de NVLink. | Reemplazar |
| NvidiaPCIeError | Evento | Las repeticiones de PCIe se activaron para recuperarse de errores de transmisión. | Ninguno |
| 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. | Ninguno |
| NvidiaPowerError | Evento | El uso de energía de las GPU superó los umbrales permitidos. | Ninguno |
| NvidiaThermalError | Evento | El estado térmico de las GPU superó los umbrales permitidos. | Ninguno |
| NvidiaXID[Código]Error | Condición | Se ha producido un error crítico de la GPU. | Reemplazar o reiniciar |
| NvidiaXID[Code]Warning | Evento | Se ha producido un error no crítico de la GPU. | Ninguno |
## Códigos de error de NVIDIA XID
El agente de supervisión de nodos detecta los errores de NVIDIA XID en los registros del kernel de la GPU. Los errores XID se dividen en dos categorías:
+ **Códigos XID conocidos**: errores críticos que establecen una condición de nodo (`AcceleratedHardwareReady=False`) y desencadenan la reparación automática cuando están habilitados. Motivo por el que el formato del código es `NvidiaXID[Code]Error`. Es posible que los códigos XID conocidos que detecta el agente de supervisión de nodos EKS no representen la lista completa de códigos de NVIDIA XID que requieren acciones de reparación.
+ **Códigos XID desconocidos**: se registran únicamente como eventos de Kubernetes. No desencadenan la reparación automática. Motivo por el que el formato del código es `NvidiaXID[Code]Warning`. Para investigar errores XID desconocidos, revise los registros del kernel con`dmesg | grep -i nvrm`.
Para obtener más información sobre los errores de XID, consulte [Errores de Xid](https://docs.nvidia.com/deploy/xid-errors/index.html#topic_5_1) 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](https://docs.nvidia.com/deploy/gpu-debug-guidelines/index.html#understanding-xid-messages) en la *documentación sobre implementación y administración de GPU de NVIDIA*.
La siguiente tabla muestra los códigos XID más conocidos, sus significados y la acción de reparación de nodos predeterminada si está habilitada.
| Código XID | Descripción | Acción de reparación |
| --- | --- | --- |
| 13 | Excepción en el motor gráfico: se produjo un error en el motor gráfico de la GPU, normalmente provocado por problemas de software o errores de controlador. | Reboot |
| 31 | Error de página en la memoria de la GPU: una aplicación intentó acceder a la memoria de la GPU que no está asignada ni accesible. | Reboot |
| 48 | Error de ECC de doble bit: se produjo un error de doble bit incorregible en la memoria de la GPU, lo que indica una posible degradación del hardware. | Reboot |
| 63 | Evento de reasignación de la memoria de la GPU: el controlador de la GPU reasignó una parte de la memoria de la GPU debido a errores detectados. Suele ser recuperable. | Reboot |
| 64 | Error al reasignar la memoria de la GPU: la GPU no pudo reasignar la memoria defectuosa, lo que indica problemas de hardware. | Reboot |
| 74 | Error de NVLink: se produjo un error en la interconexión NVLink de alta velocidad entre las GPU. | Reemplazar |
| 79 | La GPU se ha caído del bus: ya no se puede acceder a la GPU a través de PCIe, lo que suele indicar un fallo de hardware o un problema de alimentación. | Reemplazar |
| 94 | Error de memoria contenida: se produjo un error de memoria, pero estaba contenida y no afectó a otras aplicaciones. | Reboot |
| 95 | Error de memoria no contenida: se produjo un error de memoria que puede haber afectado a otras aplicaciones o a la memoria del sistema. | Reboot |
| 119 | Tiempo de espera del RPC de GSP: se agotó el tiempo de espera de la comunicación con el procesador del sistema de la GPU, posiblemente debido a problemas de firmware. | Reemplazar |
| 120 | Error GSP: se produjo un error en el procesador del sistema de la GPU. | Reemplazar |
| 121 | Error C2C: se produjo un error en la interconexión chip a chip (utilizada en las GPU de varios chips). | Reemplazar |
| 140 | Error de ECC no recuperado: un error de ECC escapó a la contención y puede haber dañado los datos. | Reemplazar |
Para ver las condiciones actuales de los nodos relacionadas con el estado de la GPU, ejecute el siguiente comando.
```
kubectl get nodes -o custom-columns='NAME:.metadata.name,ACCELERATOR_READY:.status.conditions[?(@.type=="AcceleratedHardwareReady")].status,REASON:.status.conditions[?(@.type=="AcceleratedHardwareReady")].reason'
```
Para ver los eventos relacionados con XID en el clúster, ejecute uno de los siguientes comandos.
```
kubectl get events | grep -i "NvidiaXID"
```
## 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 | Acción de reparació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. | Ninguno |
| 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). | Ninguno |
| KubeletFailed | Evento | El kubelet entró en un estado de fallo. | Ninguno |
| 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. | Ninguno |
| 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. | Reemplazar |
| 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. | Ninguno |
| [Nombre]RepeatedRestart | Evento | Una unidad systemd se reinicia con frecuencia. | Ninguno |
| ServiceFailedToStart | Evento | No se pudo iniciar una unidad de systemd. | Ninguno |
## 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 | Acción de reparació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. | Ninguno |
| AppCrash | Evento | Se colapsó una aplicación del nodo. | Ninguno |
| 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. | Ninguno |
| 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. | Ninguno |
| 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. | Ninguno |
| 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. | Ninguno |
| 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. | Reemplazar |
| 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. | Ninguno |
| 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. | Ninguno |
| 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. | Ninguno |
| SoftLockup | Evento | La CPU se detuvo durante un periodo determinado. | Ninguno |
## 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 | Acción de reparació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. | Ninguno |
| 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. | Ninguno |
| 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. | Ninguno |
| EFAErrorMetric | Evento | Las métricas del controlador EFA muestran que hay una interfaz con una degradación del rendimiento. | Ninguno |
| 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. | Ninguno |
| IPAMDNoIPs | Evento | IPAMD se quedó sin direcciones IP. | Ninguno |
| IPAMDNotReady | Condición | IPAMD no se puede conectar al servidor de la API. | Reemplazar |
| IPAMDNotRunning | Condición | El proceso de CNI de Amazon VPC no se encontró en ejecución. | Reemplazar |
| IPAMDRepeatedlyRestart | Evento | Se han producido múltiples reinicios en el servicio IPAMD. | Ninguno |
| InterfaceNotRunning | Condición | Esta interfaz parece no estar en ejecución o existen problemas de red. | Reemplazar |
| InterfaceNotUp | Condición | Parece que esta interfaz no está activa o que existen problemas de red. | Reemplazar |
| KubeProxyNotReady | Evento | Kube-proxy no pudo ver ni enumerar los recursos. | Ninguno |
| 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. | Ninguno |
| MACAddressPolicyMisconfigured | Evento | La configuración del enlace systemd-networkd tiene un valor `MACAddressPolicy` incorrecto. | Ninguno |
| MissingDefaultRoutes | Evento | Faltan reglas de ruta predeterminadas. | Ninguno |
| MissingIPRoutes | Evento | Faltan rutas para las IP de los pods. | Ninguno |
| MissingIPRules | Evento | Faltan reglas para las IP de los pods. | Ninguno |
| 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. | Reemplazar |
| NetworkSysctl | Evento | La configuración de `sysctl` de red de este nodo es potencialmente incorrecta. | Ninguno |
| 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. | Ninguno |
| 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`. | Ninguno |
| UnexpectedRejectRule | Evento | Se encontró una regla inesperada de `REJECT` o `DROP` en las `iptables`, lo que podría bloquear el tráfico esperado. | Ninguno |
## 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 | Acción de reparación |
| --- | --- | --- | --- |
| EBSInstanceIOPSExceeded | Evento | Se ha superado el máximo de IOPS de la instancia. | Ninguno |
| EBSInstanceThroughputExceeded | Evento | Se ha superado el rendimiento máximo de la instancia. | Ninguno |
| EBSVolumeIOPSExceeded | Evento | Se ha superado el máximo de IOPS para un volumen de EBS concreto. | Ninguno |
| EBSVolumeThroughputExceeded | Evento | Se ha superado el rendimiento máximo de un volumen de Amazon EBS concreto. | Ninguno |
| 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`. | Ninguno |
| 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. | Ninguno |
| 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. | Ninguno |
| 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. | Ninguno |
## Configuración del agente de supervisión de nodos
El agente de supervisión de nodos EKS se implementa como DaemOnset. Al implementarlo como un complemento de EKS, puede personalizar la instalación con los siguientes valores de configuración. Para ver las configuraciones predeterminadas, consulte el [gráfico de Helm](https://github.com/aws/eks-node-monitoring-agent/blob/main/charts/eks-node-monitoring-agent/values.yaml) del agente de supervisión de nodos de EKS.
| Opción de configuración | Descripción |
| --- | --- |
| `monitoringAgent.resources.requests.cpu` | Solicitud de recursos de CPU para el agente de supervisión. |
| `monitoringAgent.resources.requests.memory` | Solicitud de recursos de memoria para el agente de supervisión. |
| `monitoringAgent.resources.limits.cpu` | Límite de recursos de CPU para el agente de supervisión. |
| `monitoringAgent.resources.limits.memory` | Límite de recursos de memoria para el agente de supervisión. |
| `monitoringAgent.tolerations` | Tolerancias para programar el agente de supervisión en nodos con taint. |
| `monitoringAgent.additionalArgs` | Argumentos de línea de comandos opcionales que se trasladarán al agente de supervisión único. |
**nota**
Puede configurar `hostname-override` y `verbosity` como `monitoringAgent.additionalArgs` con los complementos de EKS o la instalación de Helm. Actualmente no se pueden personalizar los agentes de supervisión de nodos `probe-address` (`8002`) o `metrics-address` (`8003`) mediante argumentos adicionales con los complementos de EKS o la instalación de Helm.
El agente de supervisión de nodos incluye un componente de servidor NVIDIA DCGM (administrador de GPU del centro de datos) (`nv-hostengine`) para supervisar las GPU de NVIDIA. Este componente solo se ejecuta en los nodos que son del tipo de instancia de GPU de NVIDIA, como muestra `nodeAffinity` en el [gráfico de Helm](https://github.com/aws/eks-node-monitoring-agent/blob/main/charts/eks-node-monitoring-agent/values.yaml) del agente. No puede usar una instalación DCGM de NVIDIA existente con el agente de supervisión de nodos de EKS. Si necesita esta funcionalidad, envíenos sus comentarios sobre la hoja de ruta de EKS en [GitHub, problema número 2763](https://github.com/aws/containers-roadmap/issues/2763).
Al implementar el agente de supervisión de nodos de EKS como un complemento de EKS, puede personalizar la instalación de DCGM de NVIDIA con los siguientes valores de configuración.
| Opción de configuración | Descripción |
| --- | --- |
| `dcgmAgent.resources.requests.cpu` | Solicitud de recursos de CPU para el agente de DCGM. |
| `dcgmAgent.resources.requests.memory` | Solicitud de recursos de memoria para el agente de DCGM. |
| `dcgmAgent.resources.limits.cpu` | Límite de recursos de CPU para el agente de DCGM. |
| `dcgmAgent.resources.limits.memory` | Límite de recursos de memoria para el agente de DCGM. |
| `dcgmAgent.tolerations` | Tolerancias para programar el agente de DCGM en nodos con taint. |
Puede usar los siguientes comandos de la AWS CLI para obtener información útil sobre las versiones y el esquema del complemento de EKS del agente de supervisión de nodos EKS.
Obtenga la última versión del complemento de agente para su versión de Kubernetes. Sustituya `1.35` por su versión de Kubernetes.
```
aws eks describe-addon-versions \
--addon-name eks-node-monitoring-agent \
--kubernetes-version 1.35 \
--query='addons[].addonVersions[].addonVersion'
```
Obtenga el esquema de complementos del agente compatible con los complementos de EKS. Sustituya `v1.5.1-eksbuild.1` por su versión de agente.
```
aws eks describe-addon-configuration \
--addon-name eks-node-monitoring-agent \
--addon-version v1.5.1-eksbuild.1
```
# Reparación automática de nodos en clústeres de EKS
En este tema se detalla el comportamiento de la reparación automática de nodos de EKS y cómo configurarlo para que cumpla con sus requisitos. La reparación automática de nodos de EKS está habilitada de forma predeterminada en el modo automático de EKS y se puede utilizar con los grupos de nodos administrados por EKS y con Karpenter.
Las acciones predeterminadas de reparación automática de nodos de EKS se resumen en la siguiente tabla y se aplican al comportamiento del modo automático de EKS, los grupos de nodos administrados por EKS y Karpenter. Cuando se utiliza el modo automático de EKS o Karpenter, todas las acciones de reparación de `AcceleratedHardwareReady` son `Replace`, y solo los grupos de nodos administrados por EKS admiten `Reboot` como acción de reparación.
Para obtener una lista detallada de los problemas de estado de los nodos detectados por el agente de supervisión de nodos de EKS y sus correspondientes acciones de reparación de nodos, consulte [Detecte problemas de estado de los nodos con el agente de supervisión de nodos EKS](node-health-nma.md).
| Condiciones de nodos | Descripción | Reparación posterior | Acciones de reparación |
| --- | --- | --- | --- |
| AcceleratedHardwareReady | AcceleratedHardwareReady indica si el hardware acelerado (GPU, Neuron) del nodo funciona correctamente. | 10 m | Reemplazar o reiniciar |
| ContainerRuntimeReady | ContainerRuntimeReady indica si el tiempo de ejecución del contenedor (containerd, etc.) funciona correctamente y puede ejecutar contenedores. | 30 m | Reemplazar |
| DiskPressure | DiskPressure es una condición estándar de Kubernetes que indica que el nodo está bajo presión en el disco (poco espacio en disco o gran cantidad de E/S). | N/A | Ninguno |
| KernelReady | KernelReady indica si el kernel funciona correctamente sin errores críticos, problemas o agotamiento de los recursos. | 30 m | Reemplazar |
| Presión de memoria | MemoryPressure es una condición estándar de Kubernetes que indica que el nodo está experimentando una presión de memoria (poca memoria disponible). | N/A | Ninguno |
| NetworkingReady | NetworkingReady indica si la pila de redes del nodo funciona correctamente (interfaces, enrutamiento, conectividad). | 30 m | Reemplazar |
| StorageReady | StorageReady indica si el subsistema de almacenamiento del nodo funciona correctamente (discos, sistemas de archivos, E/S). | 30 m | Reemplazar |
| Ready | Listo es la condición estándar de Kubernetes que indica que el nodo está en buen estado y listo para aceptar pods. | 30 m | Reemplazar |
Las acciones de reparación automática de nodos de EKS están deshabilitadas de forma predeterminada en los siguientes escenarios. Las acciones de reparación de nodos en curso continúan en cada escenario. Consulte [Configuración de la reparación automática de nodos](#configure-node-repair) para saber cómo anular esta configuración predeterminada.
**Grupos de nodos administrados por EKS**
+ 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.
+ Un cambio de zona para el clúster se desencadena a través del Controlador de recuperación de aplicaciones (ARC).
**Modo automático de EKS y Karpenter**
+ Más del 20 % de los nodos del NodePool están en mal estado.
+ En el caso de los NodeClaims independientes, el 20 % de los nodos del clúster están en mal estado.
## Configuración de la reparación automática de nodos
La reparación automática de nodos no se puede configurar cuando se utiliza el modo automático de EKS y siempre está activado con los mismos ajustes predeterminados que Karpenter.
### Karpenter
Para utilizar la reparación automática de nodos con Karpenter, active la puerta de características `NodeRepair=true`. Puede habilitar las puertas de características mediante la opción `--feature-gates` de la CLI o la variable de entorno `FEATURE_GATES` en la implementación de Karpenter. Para obtener más información, consulte la documentación de [Karpenter](https://karpenter.sh/docs/concepts/disruption/#node-auto-repair).
### Grupos de nodos administrados
Puede activar la reparación automática de nodos al crear nuevos grupos de nodos administrados por EKS o al actualizar los grupos de nodos administrados por EKS existentes.
+ **Consola Amazon EKS**: seleccione 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](create-managed-node-group.md).
+ **AWS CLI**: agregue `--node-repair-config enabled=true` al comando [https://docs.aws.amazon.com/cli/latest/reference/eks/create-nodegroup.html](https://docs.aws.amazon.com/cli/latest/reference/eks/create-nodegroup.html) o [https://docs.aws.amazon.com/cli/latest/reference/eks/update-nodegroup-config.html](https://docs.aws.amazon.com/cli/latest/reference/eks/update-nodegroup-config.html).
+ **eksctl**: configure `managedNodeGroups.nodeRepairConfig.enabled: true` y consulte el ejemplo en el [GitHub de eksctl](https://github.com/eksctl-io/eksctl/blob/main/examples/44-node-repair.yaml).
Al utilizar grupos de nodos administrados por EKS, puede controlar el comportamiento de reparación automática de los nodos con los siguientes ajustes.
Para controlar cuándo la reparación automática de nodos deja de funcionar, establezca un umbral en función del número de nodos en mal estado del grupo de nodos. Establezca el porcentaje o el recuento absoluto, pero no ambos.
| Opción | Descripción |
| --- | --- |
| `maxUnhealthyNodeThresholdCount` | El número absoluto de nodos en mal estado por encima del cual se detiene la reparación automática de nodos. Úselo para limitar el alcance de las reparaciones. |
| `maxUnhealthyNodeThresholdPercentage` | El número absoluto de nodos en mal estado por encima del cual se detiene la reparación automática de nodos (0-100). |
Para controlar el número de nodos que se reparan al mismo tiempo, puede configurar el paralelismo de reparación. Al igual que con el umbral de nodos en mal estado, establezca el porcentaje o el recuento absoluto, pero no ambos.
| Opción | Descripción |
| --- | --- |
| `maxParallelNodesRepairedCount` | El número máximo de nodos para la reparación simultánea. |
| `maxParallelNodesRepairedPercentage` | El porcentaje máximo de nodos en mal estado que se pueden reparar simultáneamente (0-100). |
Con `nodeRepairConfigOverrides`, puede personalizar el comportamiento de reparación para condiciones específicas. Úselo cuando necesite diferentes acciones de reparación o tiempos de espera para diferentes tipos de problemas.
Cada anulación requiere los siguientes campos:
| Campo | Descripción |
| --- | --- |
| `nodeMonitoringCondition` | El tipo de condición del nodo notificada por el agente de supervisión de nodos. Por ejemplo: `AcceleratedHardwareReady`, `NetworkingReady`, `StorageReady`, `KernelReady`. |
| `nodeUnhealthyReason` | El código de motivo específico de la condición de mal estado. Por ejemplo: `NvidiaXID31Error`, `IPAMDNotRunning`. |
| `minRepairWaitTimeMins` | El tiempo mínimo (en minutos) que debe persistir la condición de reparación antes de que el nodo sea elegible para la reparación. Utilícelo para evitar reparar los nodos por problemas temporales. |
| `repairAction` | La acción que se debe realizar cuando se cumplen las condiciones. Valores válidos: `Replace` (terminar y reemplazar el nodo), `Reboot` (reiniciar el nodo) o `NoAction` (sin acciones de reparación). |
El siguiente ejemplo de la AWS CLI crea un grupo de nodos con una configuración de reparación personalizada.
```
aws eks create-nodegroup \
--cluster-name my-cluster \
--nodegroup-name my-nodegroup \
--node-role arn:aws:iam::111122223333:role/NodeRole \
--subnets subnet-0123456789abcdef0 \
--node-repair-config '{
"enabled": true,
"maxUnhealthyNodeThresholdPercentage": 10,
"maxParallelNodesRepairedCount": 3,
"nodeRepairConfigOverrides": [
{
"nodeMonitoringCondition": "AcceleratedHardwareReady",
"nodeUnhealthyReason": "NvidiaXID64Error",
"minRepairWaitTimeMins": 5,
"repairAction": "Replace"
},
{
"nodeMonitoringCondition": "AcceleratedHardwareReady",
"nodeUnhealthyReason": "NvidiaXID31Error",
"minRepairWaitTimeMins": 15,
"repairAction": "NoAction"
}
]
}'
```
Esta configuración hace lo siguiente:
+ Permite la reparación automática de nodos
+ Detiene las acciones de reparación cuando más del 10 % de los nodos están en mal estado
+ Repara hasta 3 nodos a la vez
+ Anula los errores XID 64 (error de reasignación de la memoria de la GPU) para reemplazar el nodo después de 5 minutos. El valor predeterminado para el reinicio es tras 10 minutos.
+ Anula los errores XID 31 (error de página en la memoria de la GPU) para no realizar ninguna acción. El valor predeterminado para el reinicio es tras 10 minutos.
# Cómo ver el estado de los nodos
En este tema se explican las herramientas y métodos que existen para supervisar el estado de los nodos en los clústeres de Amazon EKS. La información abarca condiciones, eventos y casos de detección de nodos útiles a la hora de identificar y diagnosticar problemas a nivel de nodo. Utilice los comandos y patrones descritos aquí para inspeccionar los recursos de estado de los nodos, interpretar las condiciones de estado y analizar los eventos de los nodos para la resolución de problemas operativos.
Puede obtener información sobre el estado de los nodos con comandos de Kubernetes para todos los nodos. Además, si utiliza el agente de supervisión de nodos a través del modo automático de Amazon EKS o el complemento administrado de Amazon EKS, obtendrá una mayor variedad de señales de nodos útiles para la resolución de problemas. Las descripciones de los problemas de estado detectados por el agente de supervisión de nodos también se encuentran disponibles en el panel de observabilidad. Para obtener más información, consulte [Detecte problemas de estado de los nodos con el agente de supervisión de nodos EKS](node-health-nma.md).
## Condiciones de nodos
Las condiciones del nodo representan problemas en el terminal que requieren acciones correctoras, como la sustitución de la instancia o el reinicio.
**Para obtener las condiciones de todos los nodos:**
```
kubectl get nodes -o 'custom-columns=NAME:.metadata.name,CONDITIONS:.status.conditions[*].type,STATUS:.status.conditions[*].status'
```
**Para obtener las condiciones detalladas de un nodo específico**
```
kubectl describe node node-name
```
**Ejemplo del resultado de condición de un nodo en buen estado:**
```
- lastHeartbeatTime: "2024-11-21T19:07:40Z"
lastTransitionTime: "2024-11-08T03:57:40Z"
message: Monitoring for the Networking system is active
reason: NetworkingIsReady
status: "True"
type: NetworkingReady
```
**Ejemplo de condición de un nodo en mal estado con un problema de red:**
```
- lastHeartbeatTime: "2024-11-21T19:12:29Z"
lastTransitionTime: "2024-11-08T17:04:17Z"
message: IPAM-D has failed to connect to API Server which could be an issue with
IPTable rules or any other network configuration.
reason: IPAMDNotReady
status: "False"
type: NetworkingReady
```
## Eventos de nodos
Los eventos de nodos indican problemas temporales o configuraciones que no son óptimas.
**Para obtener todos los eventos notificados por el agente de supervisión de nodos**
Si el agente de supervisión de nodos está disponible, puede ejecutar el siguiente comando.
```
kubectl get events --field-selector=reportingComponent=eks-node-monitoring-agent
```
Código de salida de ejemplo:
```
LAST SEEN TYPE REASON OBJECT MESSAGE
4s Warning SoftLockup node/ip-192-168-71-251.us-west-2.compute.internal CPU stuck for 23s
```
**Para obtener eventos de todos los nodos**
```
kubectl get events --field-selector involvedObject.kind=Node
```
**Para obtener eventos de un nodo específico**
```
kubectl get events --field-selector involvedObject.kind=Node,involvedObject.name=node-name
```
**Para ver eventos en tiempo real**
```
kubectl get events -w --field-selector involvedObject.kind=Node
```
**Ejemplo de resultado de un evento:**
```
LAST SEEN TYPE REASON OBJECT MESSAGE
2m Warning MemoryPressure Node/node-1 Node experiencing memory pressure
5m Normal NodeReady Node/node-1 Node became ready
```
## Comandos de resolución de problemas habituales
```
# Get comprehensive node status
kubectl get node node-name -o yaml
# Watch node status changes
kubectl get nodes -w
# Get node metrics
kubectl top node
```
# Recuperación de los registros de nodos de un nodo administrado mediante kubectl y S3
Aprenda a recuperar los registros de nodos de un nodo administrado por Amazon EKS que tenga el agente de supervisión de nodos.
## Requisitos previos
Asegúrese de contar con lo siguiente:
+ Un clúster de Amazon EKS con el agente de supervisión de nodos existente. Para obtener más información, consulte [Detección de los problemas de estado de los nodos y reparación automática de los nodos](node-health.md).
+ La herramienta de línea de comandos `kubectl` instalada y configurada para comunicarse con el clúster.
+ AWS CLI instalada y sesión iniciada con los permisos suficientes para crear buckets y objetos de S3.
+ Una versión reciente de Python 3 instalada
+ El SDK de AWS para Python 3 y Boto 3 instalado.
## Paso 1: Creación de un destino de bucket de S3 (opcional)
Si aún no tiene un bucket de S3 para almacenar los registros, cree uno. Utilice el siguiente comando de AWS CLI. El bucket utiliza de manera predeterminada la lista de control de acceso `private`. Sustituya *bucket-name* por el nombre único que haya elegido.
```
aws s3api create-bucket --bucket
```
## Paso 2: Creación de una URL de S3 previamente firmada para HTTP Put
Amazon EKS devuelve los registros de nodo mediante una operación HTTP PUT a una URL especificada. En este tutorial, generaremos una URL de HTTP PUT de S3 previamente firmada.
Los registros se devolverán como un gzip tarball, con la extensión `.tar.gz`.
**nota**
Debe usar la API de AWS o un SDK para crear la URL de carga previamente firmada de S3 para que EKS cargue el archivo de registro. No puede crear una URL de carga previamente firmada de S3 mediante AWS CLI.
1. Determine en qué parte del bucket desea almacenar los registros. Por ejemplo, puede utilizar *2024-11-12/logs1.tar.gz* como clave.
1. Copie el siguiente código de Python en el archivo *presign-upload.py*. Sustituya ** y **. La clave debe terminar con `.tar.gz`.
```
import boto3; print(boto3.client('s3').generate_presigned_url(
ClientMethod='put_object',
Params={'Bucket': '', 'Key': ''},
ExpiresIn=1000
))
```
1. Ejecute el script con
```
python presign-upload.py
```
1. Anote la URL de resultado. Utilice este valor en el siguiente paso como *http-put-destination*.
Para obtener más información, consulte [Generate a presigned URL to upload a file](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/s3-presigned-urls.html#generating-a-presigned-url-to-upload-a-file) en la documentación del AWS SDK para Python Boto3.
## Paso 3: Creación del recurso de NodeDiagnostic
Identifique el nombre del nodo del que desea recopilar los registros.
Cree un manifiesto `NodeDiagnostic` que utilice el nombre del nodo como nombre del recurso y que proporcione un destino de URL de HTTP PUT.
```
apiVersion: eks.amazonaws.com/v1alpha1
kind: NodeDiagnostic
metadata:
name:
spec:
logCapture:
destination: http-put-destination
```
Aplique el manifiesto al clúster.
```
kubectl apply -f nodediagnostic.yaml
```
Para comprobar el estado de la recopilación, puede describir el recurso `NodeDiagnostic`:
+ Un estado de `Success` o `SuccessWithErrors` indica que la tarea se completó y los registros se cargaron en el destino indicado (`SuccessWithErrors` indica que es posible que falten algunos registros)
+ Si el estado es Error, confirme que la URL de carga esté formada correctamente y no haya caducado.
```
kubectl describe nodediagnostics.eks.amazonaws.com/
```
## Paso 4: Descarga de los registros de S3
Espere aproximadamente un minuto antes de intentar descargar los registros. A continuación, use la CLI de S3 para descargar los registros.
```
# Once NodeDiagnostic shows Success status, download the logs
aws s3 cp s3:///key ./.tar.gz
```
## Paso 5: Cómo limpiar el recurso de NodeDiagnostic
+ Los recursos de `NodeDiagnostic` no se eliminan automáticamente. Deberá limpiarlos por cuenta propia después de haber obtenido los artefactos de registro
```
# Delete the NodeDiagnostic resource
kubectl delete nodediagnostics.eks.amazonaws.com/
```
## Destino `node` de NodeDiagnostic
A partir de la versión `v1.6.0` del agente de supervisión de nodos, existe la opción de establecer el destino de la recopilación de registros en `node`. El uso de este destino permitirá recopilar y conservar temporalmente los registros en el nodo para su posterior recopilación. Además de esta funcionalidad, en el repositorio de GitHub del agente de supervisión de nodos hay un complemento `kubectl` que puede instalar para facilitar la interacción y la recopilación de registros. Para obtener más información, consulte la [documentación del complemento `kubectl ekslogs`](https://github.com/aws/eks-node-monitoring-agent/blob/main/tools/kubectl-ekslogs/README.md).
## Ejemplo de uso
```
# Collect NodeDiagnostic logs from a single node
kubectl ekslogs
# Collect NodeDiagnostic logs from multiple nodes
kubectl ekslogs
# Collect NodeDiagnostic logs from all nodes with a specific label
kubectl ekslogs -l =
```