Kubernetes 1.36 : gestion des pannes de GPU sans attente infinie
NVIDIA
Meta
Dans Kubernetes, une panne de dispositif GPU n'entraîne pas automatiquement le replanification des pods ; au lieu de cela, le kubelet redémarre le conteneur sur le même dispositif défectueux, provoquant une boucle de plantage. L'article illustre ce scénario sur un banc d'essai et montre comment les nouveaux mécanismes de Kubernetes 1.36, tels que le statut de santé des dispositifs et les marques, peuvent briser ce cycle.
L'article souligne que Kubernetes, par défaut, gère les pannes de dispositifs en redémarrant simplement le conteneur, ce qui est insuffisant pour les charges de travail accélérées par GPU. Citant une étude de Meta sur l'entraînement de Llama 3 405B, il note que les clusters avec des milliers de GPU subissent des interruptions fréquentes, souvent dues à des pannes de GPU et de mémoire. L'auteur explique les limites de l'approche classique des plugins de dispositifs, qui ne fait que réduire le nombre allouable, et la compare au modèle plus récent de DRA (allocation dynamique des ressources), qui fournit une gestion des dispositifs basée sur des objets. Sur un cluster de test, l'auteur simule une panne de GPU en retirant à chaud un dispositif du bus PCIe, ce qui entraîne une erreur Xid 79. Le pod entre alors dans une boucle de crash, redémarrant sur le dispositif défectueux, et l'ordonnanceur ne le replanifie pas car il est toujours lié au nœud. Kubernetes 1.36 introduit plusieurs fonctionnalités bêta pour remédier à cela : l'état de santé des dispositifs dans le statut du pod, les teintes (taints) et tolérances de dispositifs, et les dispositifs partitionnables. Grâce à ces fonctionnalités, le cluster peut être amené à reconnaître la panne et à planifier le pod sur un GPU sain, évitant ainsi des redémarrages sans fin.
Source: Habr — хаб ML —
original
