Kubernetes에서 GPU 장애 처리: 끝없는 Pending 상태 없이 장치 고장 다루기

이 글은 Meta가 Llama 3 405B를 훈련하면서 겪은 경험을 소개하는데, H100 GPU 16,384개로 구성된 클러스터에서 총 419건의 중단이 발생했고 이 중 58.7%가 GPU 관련 문제였다고 밝힌다. 저자는 쿠버네티스(Kubernetes)가 전통적으로 디바이스 장애를 상태 비저장(stateless) 서비스 장애와 동일하게 취급해, 이미 고장 난 동일한 GPU에서 재시작을 시도함으로써 결국 크래시 루프(crash loop)로 이어진다는 문제를 지적한다. 이를 해결하기 위해 쿠버네티스 1.36에서는 여러 메커니즘이 도입되었다. 1.34부터 안정화된 DRA(Dynamic Resource Allocation, 동적 리소스 할당)는 단순한 카운터 방식 대신 객체 기반 모델을 제공하며, 백업 디바이스를 위한 우선순위 목록(firstAvailable) 기능, 파드 상태에 표시되는 디바이스 헬스 상태, 디바이스 테인트(taint)와 톨러레이션(toleration), 그리고 디바이스 바인딩 조건 등이 함께 도입되었다. 저자는 GPU 노드가 포함된 VK Cloud Managed Kubernetes 1.36 환경에 테스트 스탠드를 구축하고, PCIe 디바이스를 핫 제거(hot-remove)하는 방식으로 GPU 장애를 시뮬레이션한다. 그 결과 노드는 해당 디바이스를 비정상(unhealthy)으로 보고하고 할당 가능한 개수도 줄어들지만, 파드는 재스케줄링 없이 죽은 GPU에서 계속 재시작을 반복한다는 사실을 보여준다. 마지막으로 이 글은 쿠버네티스가 왜 CrashLoopBackOff 상태의 파드에 대한 내장형 디스케줄링(descheduling) 기능을 제공하지 않는지를 설명하고, 노드 전체를 강제 종료해버리는 노드 헬스 컨트롤러 같은 임시방편(DIY) 패턴들을 언급하며, 이런 방식이 다소 무딘 해결책이라고 평가한다.