GPU-fouten in Kubernetes: omgaan met apparaatfouten zonder eindeloos in Pending te blijven
Meta
NVIDIA
In 2024 ondervond Meta's cluster van 16.384 H100's, dat Llama 3 405B trainde, 419 onderbrekingen, waarvan 58,7% werd toegeschreven aan GPU's. Kubernetes gaat vaak met dergelijke fouten om door simpelweg containers op hetzelfde defecte apparaat opnieuw te starten, wat leidt tot eindeloze Pending-status. Dit artikel legt uit hoe de nieuwe functies voor Dynamic Resource Allocation (DRA) in Kubernetes 1.36 eindelijk een oplossing bieden, met behulp van een live demo op een beheerd VK Cloud-cluster.
Het artikel belicht de ervaring van Meta met het trainen van Llama 3 405B, waarbij het cluster van 16.384 H100-GPU's 419 onderbrekingen kende, waarvan 58,7 procent GPU-gerelateerd was. Het wijst erop dat Kubernetes apparaatfouten traditioneel behandelt als fouten bij stateless services, door een herstart te proberen op dezelfde defecte GPU, wat leidt tot een crash loop. Om dit aan te pakken introduceert Kubernetes 1.36 verschillende mechanismen: DRA (Dynamic Resource Allocation) is stabiel sinds versie 1.34 en biedt een objectgebaseerd model in plaats van een eenvoudige teller; een geprioriteerde lijst (firstAvailable) voor back-upapparaten; de gezondheidsstatus van apparaten in de podstatus; device taints en tolerations; en device binding conditions, onder andere. De auteur bouwt een testopstelling op VK Cloud Managed Kubernetes 1.36 met een GPU-node en simuleert een GPU-storing door het PCIe-apparaat hot te verwijderen. Ze laten zien dat de node het apparaat als ongezond meldt en dat het aantal toewijsbare apparaten daalt, maar dat de pod blijft herstarten op de dode GPU zonder dat er opnieuw wordt gepland. Het artikel concludeert door uit te leggen waarom Kubernetes geen ingebouwde descheduling biedt voor pods in CrashLoopBackOff en noemt DIY-patronen zoals node health controllers die de hele node uitschakelen, wat een grof middel is.
Bron: Habr — хаб ML —
origineel