KubernetesにおけるGPU障害：無限にPending状態になることを避けるデバイス障害への対処法

この記事は、MetaがLlama 3 405Bをトレーニングした際の経験を強調しており、16,384基のH100 GPUのクラスタで419回の中断が発生し、その58.7%がGPU関連であることを示しています。Kubernetesは伝統的にデバイス障害をステートレスサービスの障害のように扱い、同じ壊れたGPU上での再起動を試みるため、クラッシュループにつながると指摘しています。これに対処するため、Kubernetes 1.36ではいくつかのメカニズムが導入されています：DRA（Dynamic Resource Allocation、動的リソース割り当て）は1.34以降安定版であり、単純なカウンターではなくオブジェクトベースのモデルを提供します；バックアップデバイスのための優先リスト（firstAvailable）；ポッドステータスにおけるデバイスの健全性ステータス；デバイスのテイントとトレランス；デバイスのバインディング条件などです。著者は、VK Cloud Managed Kubernetes 1.36上にGPUノードを備えたテストスタンドを構築し、PCIeデバイスをホットリムーブすることでGPU障害をシミュレートしています。ノードがデバイスを不健全として報告し、割り当て可能な数が減少するものの、ポッドは再スケジュールされることなく、死んだGPU上で再起動を続けることを示しています。この記事は、なぜKubernetesがCrashLoopBackOff状態のポッドに対して組み込みのデスケジューリングを提供しないのかを説明し、ノード全体を殺すノードヘルスコントローラのようなDIYパターンに言及しつつ、それは鈍器であると述べて結論付けています。