Pannes GPU dans Kubernetes : gérer les défaillances matérielles sans boucle infinie de pending

L'article met en lumière l'expérience de Meta lors de l'entraînement de Llama 3 405B, où le cluster de 16 384 GPU H100 a connu 419 interruptions, dont 58,7 % liées aux GPU. Il souligne que Kubernetes traite traditionnellement les pannes de périphériques comme des pannes de services sans état, tentant un redémarrage sur le même GPU défectueux, ce qui entraîne une boucle de redémarrage. Pour y remédier, Kubernetes 1.36 introduit plusieurs mécanismes : la DRA (Dynamic Resource Allocation) est stable depuis la version 1.34, offrant un modèle basé sur des objets plutôt qu'un simple compteur ; la liste priorisée (firstAvailable) pour les périphériques de secours ; le statut de santé des périphériques dans le statut des pods ; les taints et tolérances de périphériques ; et les conditions de liaison des périphériques, entre autres. L'auteur construit un banc d'essai sur VK Cloud Managed Kubernetes 1.36 avec un nœud GPU et simule une panne de GPU en retirant à chaud le périphérique PCIe. Il montre que le nœud signale le périphérique comme non sain et que le nombre allouable diminue, mais le pod continue de redémarrer sur le GPU mort sans aucune replanification. L'article conclut en expliquant pourquoi Kubernetes n'offre pas de déscheduling intégré pour les pods en CrashLoopBackOff et mentionne des modèles de bricolage comme les contrôleurs de santé de nœuds qui tuent tout le nœud, ce qui est un outil grossier.