Kubernetes 1.36: Umgang mit GPU-Geräteausfällen ohne endloses Pending
NVIDIA
Meta
In Kubernetes führt ein GPU-Geräteausfall nicht automatisch zur Neuplanung des Pods; stattdessen startet der Kubelet den Container auf demselben defekten Gerät neu, was eine Crash-Schleife verursacht. Der Artikel demonstriert dieses Szenario auf einem Testaufbau und zeigt, wie neue Mechanismen in Kubernetes 1.36, wie Gerätegesundheitsstatus und Taints, den Kreislauf durchbrechen können.
Der Artikel hebt hervor, dass Kubernetes standardmäßig Geräteausfälle behandelt, indem es den Container einfach neu startet, was für GPU-beschleunigte Workloads unzureichend ist. Unter Berufung auf eine Meta-Studie zum Training von Llama 3 405B wird darauf hingewiesen, dass Cluster mit Tausenden von GPUs häufige Unterbrechungen erleben, oft aufgrund von GPU- und Speicherausfällen. Der Autor erklärt die Einschränkungen des klassischen Geräte-Plugin-Ansatzes, der nur die Anzahl der zuweisbaren Geräte reduziert, und stellt ihn dem neueren DRA-Modell (Dynamic Resource Allocation) gegenüber, das eine objektbasierte Geräteverwaltung bietet. Auf einem Testcluster simuliert der Autor einen GPU-Ausfall, indem er ein Gerät per PCIe-Bus entfernt, was zu Xid 79 führt. Der Pod gerät dann in eine Crash-Schleife, startet auf dem defekten Gerät neu, und der Scheduler plant ihn nicht neu, weil er weiterhin an den Knoten gebunden ist. Kubernetes 1.36 führt mehrere Betafunktionen ein, um dieses Problem zu beheben: Gerätegesundheitsstatus im Pod-Status, Geräte-Taints und Tolerierungen sowie partitionierbare Geräte. Mit diesen kann der Cluster den Ausfall erkennen und den Pod auf eine gesunde GPU umplanen, wodurch endlose Neustarts vermieden werden.
Quelle: Habr — хаб ML —
Original
