El incidente describe la problemática recurrente de fallas de hardware en nodos de Kubernetes a escala de hyperscaler, particularmente en entornos con GPUs. La causa raíz es la naturaleza inevitable de las fallas de hardware 'raras' que, a gran escala, ocurren con frecuencia. Inicialmente, la respuesta a estas fallas era manual, lo que resultaba en degradación prolongada del servicio y 'toil' operativo.
La solución implementada, el EKS Node Monitoring Agent junto con Karpenter, automatiza la detección y reparación. Sin embargo, el artículo detalla varias trampas y lecciones aprendidas durante su operación. Una falla clave en las salvaguardas iniciales fue la interpretación incorrecta de los 'reason codes' como un contrato API, lo que llevó a cambios de severidad que rompieron la automatización de los clientes. Otra fue la confusión entre 'Absent' y 'Unknown' en las condiciones de monitoreo, lo que podría llevar a reemplazos de nodos innecesarios. La latencia de detección también fue malinterpretada, ya que el cuello de botella no era el agente, sino la fuente de la señal (ej. journald).
Un problema crítico fue la interferencia del propio agente de monitoreo con las cargas de trabajo de GPU de baja latencia. Los picos de consumo de CPU del agente, debido a la alineación de los intervalos de sondeo de múltiples goroutines, causaron jitter que degradó el rendimiento de los trabajos de entrenamiento distribuido. Esto resalta que, en sistemas sensibles a la latencia, el patrón de consumo de recursos de un agente es tan importante como el consumo total. La separación de la detección y el diagnóstico también fue una lección crucial, ya que intentar hacer ambas cosas en la misma ruta caliente degradaba la velocidad de reacción del sistema.