Fallos de GPU en Kubernetes: cómo manejar fallos de dispositivos sin quedar atascados en Pending

El artículo destaca la experiencia de Meta entrenando Llama 3 405B, donde el clúster de 16,384 GPU H100 sufrió 419 interrupciones, de las cuales el 58,7% estaban relacionadas con las GPU. Señala que Kubernetes tradicionalmente trata las fallas de dispositivos como fallas de servicios sin estado, intentando reiniciar en la misma GPU averiada, lo que provoca un bucle de bloqueo. Para abordar esto, Kubernetes 1.36 introduce varios mecanismos: la asignación dinámica de recursos (DRA, por sus siglas en inglés) es estable desde la versión 1.34, proporcionando un modelo basado en objetos en lugar de un simple contador; la lista priorizada (firstAvailable) para dispositivos de respaldo; el estado de salud de los dispositivos en el estado del pod; las manchas y tolerancias de dispositivos; y las condiciones de vinculación de dispositivos, entre otros. El autor construye un banco de pruebas en VK Cloud Managed Kubernetes 1.36 con un nodo GPU y simula una falla de GPU al extraer en caliente el dispositivo PCIe. Muestran que el nodo informa que el dispositivo no está saludable y que el recuento asignable disminuye, pero el pod sigue reiniciándose en la GPU muerta sin ningún re-programación. El artículo concluye explicando por qué Kubernetes no ofrece una reprogramación integrada para los pods en estado CrashLoopBackOff y menciona patrones de bricolaje como los controladores de salud del nodo que eliminan todo el nodo, lo cual es una herramienta contundente.