EKS Bottlerocket AMI에서 DCGM 오류로 GPU 노드가 반복 교체되던 문제 해결기

인프런은 Amazon EKS 1.32와 Bottlerocket AMI(amazon/bottlerocket-aws-k8s-1.32-nvidia-aarch64-v1.39.1-3a880b44), g5g.xlarge GPU 인스턴스, Karpenter v1.4.0 조합으로 강의 영상 업스케일링용 GPU 클러스터를 운영했다. 노드 좀비 상태를 막기 위해 Node Auto-Repair(nodeRepair: true)까지 켰지만, GPU Pod를 띄운 뒤 약 10~11분마다 노드가 비정상으로 판단돼 계속 교체되는 문제가 생겼다.

핵심 단서는 노드 이벤트의 AcceleratedHardwareReady 상태였다. 노드가 Ready가 된 직후 Status: True → False, Reason: DCGMError, Message: failed to initialize DCGM: libdcgm.so not Found가 기록됐고, 이는 NVIDIA DCGM 라이브러리 누락 때문에 GPU 하드웨어 상태를 정상적으로 확인할 수 없게 됐다는 뜻이었다. GPU 연산 자체가 막힌 것은 아니었지만, DCGM 기반 상태 확인이 실패하면서 Karpenter가 해당 노드를 비정상으로 간주했다.

이후 Karpenter는 노드 풀 건강 상태를 확인한 뒤, 비정상 조건과 정책 종료 시간을 기준으로 교체를 진행했다. 글에서는 Karpenter의 로직을 다음처럼 정리한다.

• **isNodePoolHealthy()**로 노드풀 내 비정상 비율 확인
• **findUnhealthyConditions()**로 AcceleratedHardwareReady=False 같은 조건 탐지
• 정책에 따른 유예 시간 후 RequeueAfter로 재검사
• 유예 시간이 지나면 NodeClaim 삭제 및 노드 종료

결국 문제의 근본 원인은 Bottlerocket 환경에서 libdcgm.so를 직접 보강하기 어려운 데 있었다. 다른 AMI로 바꾸는 방안도 있었지만 인프라 변경 비용이 컸고, 현재 상황에서는 Node Auto-Repair를 비활성화(nodeRepair: false)하는 것이 가장 현실적인 해결책으로 선택됐다. 글은 Karpenter에서 GPU 노드가 잦은 교체를 겪는다면 먼저 AcceleratedHardwareReady와 DCGM 오류를 의심하고, 필요하면 Auto-Repair 설정을 재검토하라고 정리한다.