Docker,Kubernetes - nvidia-smi: Failed to initialize NVML: Unknown Error — cgroup 관리 주체 (systemd cgroupfs)로 인한 GPU 접근 권한 상실 이슈

배경/상황 -

• docker-compose 기반으로 GPU 컨테이너를 상시 운영하는 구성에서, 컨테이너 내부에서 주기적으로 nvidia-smi가 NVML 초기화 실패로 전환되는 문제가 제가 알기 전부터 시작해 1년 이상 반복 발생했습니다.
• Nvidia Driver(ex: 550) 커널 모듈과 유저스페이스 NVML 라이브러리의 버전을 맞춰도 문제가 지속되어, 버전 호환성만으로 설명되지 않는 케이스로 분류했습니다.
  • 커널의 주기적인 업데이트 등으로 라이브러리는 업데이트되었으나 재부팅을 하지 않아 커널 모듈의 버전 호환성이 맞지 않는 경우에도 NVML이슈가 발생될 수 있기 때문입니다.
• NVML이슈를 끝없이 확인해보며 테스트를 해도 GPU 컨테이너(LLM 엔진)가 분석을 돌다 보면 어느새 NVML이슈가 발생해 이슈를 매번 주기적으로 확인하여 restart를 해주던 것에서 진짜 원인과 해결책을 확인하게 되어 문서를 작성하게 되었습니다.
  • 이슈와 해결기간 자체는 꽤 되었지만 다시 잊지 않기 위해, 그리고 이러한 이슈가 관련된 글이 남아있었으면 좋겠다고 생각하여 작성합니다.

환경/전제 

• OS
  • Ubuntu 22.04 LTS  
  • WSL2: Wsl-ubuntu22.04 (Ubuntu 22.04)  
• Container / Orchestrator
  • Docker 기반 컨테이너 실행 환경(노드별 Docker Engine 버전 상이)  
  • Kubernetes 환경에서도 동일 증상군을 추적(노드 런타임/CGroups 영향 포함)  
•  NVIDIA Stack
  • NVIDIA Driver: 550 계열 설치  
• 컨테이너 실행 방식

# docker
services:
  engine-ctp:
    image: example-engine
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
              
# k8s
spec:
  containers:
    - name: cuda
      image: nvidia/cuda:12.2.0-base-ubuntu22.04
      command: ["bash", "-lc", "nvidia-smi && sleep 3600"]
      resources:
        limits:
          nvidia.com/gpu: "1"

문제 현상 

실무에서 이슈를 확인했던 상황과 이슈의 내용들을 통해 문제 현상을 보여드리겠습니다.

 

gpu기반의 엔진을 실행하기 위해 nvidia stack을 설치한 뒤 재부팅을 진행했고 설치 진행 과정에 대해 유효성 검증을 진행한 후 컨테이너를 구동했을 때 구동한 시점과 어느 정도의 시점까지는 엔진이 gpu를 사용해 정상적으로 분석을 진행했습니다.

•  이 어느정도의 시점은 이슈를 확인할 때마다 달라 평균적으로 가늠할 수 없었습니다.

시간이 지나 갑자기 container가 gpu를 기반으로 분석하지 못해 확인하면 매번 NVML이슈가 나왔고 이것을 확인하기 위해 짧은 간격으로 nvidia-smi로 컨테이너에서 정상적으로 사용한 지 여부를 확인하여 이슈가 있을 때마다 restart를 진행해야 다시 gpu사용이 가능했었습니다.

 

문제의 현상은 위와 같고 이슈가 발생한다면 nvidia-smi Failed to initialize NVML: Unknown Error와 같은 로그만 확인할 수 있었으며 그 내용은 하단의 사진을 통해 확인이 가능합니다.

 

컨테이너 안에서 확인했던 이슈이며 문제의 현상은 위와 같이 나오고 별다른 정보가 디버깅이 매우 힘든걸 알 수 있습니다.

• nvidia stack의 버전간 차이는 mismatch같은 힌트가 NVML: 뒤에 추가되지만 이 이슈는 별다른 정보가 나와있지 않았기 때문입니다.

현상 분석

 NVML과 블로그들을 찾아보고 정보들을 찾아볼 경우 container의 권한을 root와 같이 높이는 경우(보안상 위험), gpu를 사용하기 위해 필요한 라이브러리들을 설치하는 경우, device를 추가하는 경우 등등 다양한 방법이 있었으나 제 경우엔 모두 해결이 되지 않았습니다.

 

ubuntu/window 에서 테스트, 개발을 진행하고 있었으나 둘다 ubuntu22.04를 기반으로 os를 설치했기 때문에 os상에선 큰 차이가 있지 않다고 판단하고 container와 gpu만 주구장창 파고들던 와중 엔진을 개발하던 팀에선 NVML이슈가 없다는 얘길 전해 들었습니다.

 

그리하여 확인한 결과 os의 버전은 똑같았고 nvidia-driver와 관련된 라이브러리 등의 버전은 모두 동일했으나 이를 운영하는 docker의 차이가 존재하지 않을까?라고 생각하여 확인한 정보는 다음과 같습니다.

 

정상 노드

장애 노드(순수 ubuntu/wsl은 동일합니다)

• 정상/장애 노드의 docker info에서 관찰된 핵심 차이
  • 정상 노드: (cgroup 관리 주체/방식) 런타임이 cgroupfs로 직접 관리
  • 장애 노드: (cgroup 관리 주체/방식) systemd가 관리(위임 모델)

즉 즉 Docker Info로 확인한 결과, 컨테이너 cgroup을 systemd가 관리(위임)하는지, 아니면 컨테이너 런타임이 cgroupfs를 통해 직접 관리하는지의 차이가 있었고 이를 통해 관련된 것들을 찾아본 결과 컨테이너 cgroup 트리(/sys/fs/cgroup)를 어떤 드라이버가 관리하는지(직접 조작 vs systemd 위임)가 다르다는 것이 문제를 야기하는 주원인임을 확인할 수 있었습니다.

• 이것에 관련되어 cgroup driver가 cgroup을 관리할 때의 방식과 각각의 특성에 대한 이해가 필요하지만 이것은 따로 글을 작성하여 첨부하도록 하겠습니다.

Docker기반의 환경에선 cgroupfs을 기반으로 cgroup을 관리해야만 했는데 처음엔 잘 기능하다가 왜 중간에 이러지? 하고 확인한 근거는 다음과 같습니다.

 

NVIDIA Container Runtime Hook이 cgroup/device 설정을 저수준 런타임(runc) 관점에서 ‘인식되지 않는 방식’으로 주입하여 “컨테이너 업데이트/변경 이벤트”에 의해 GPU 접근이 사라질 수 있다고 설명합니다.

https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/troubleshooting.html

• systemctl daemon-reload만으로도 트리거 될 수 있다고 명시합니다.

systemd cgroups로 구성된 runc 환경에서, systemd가 cgroup 재평가를 수행할 때 GPU 할당 컨테이너가 GPU 접근을 잃는 이슈

https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/22.9.2/release-notes.html

 

최종 원인

• Docker 환경에서 컨테이너 cgroup을 systemd가 관리(위임)하는 구성에서는, systemd의 재평가/컨테이너 업데이트 트리거(예: systemctl daemon-reload) 시 GPU 디바이스 접근이 컨테이너에서 제거될 수 있어 NVML 초기화가 실패했습니다.
  [NVIDIA GPU Operator Docs | Release Notes > 22.9.2 Fixed issues | 22.9.2 | 2026-01-14 | https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/22.9.2/release-notes.html]

 

이렇게 문제를 확인한 과정에서 Docker환경에서는 NVML이 발생하고 똑같이 cgroup driver가 systemd임에도 kubernetes에선 발생하지 않아 왜 그렇지? 하고 확인해 보니 kubernetes에선 gpu operator를 사용하고 있었고 이것이 systemd임에도 nvidia driver에 대한 접근 권한 상실 등에 대한 문제를 해결했기 때문임을 알 수 있었습니다.

https://github.com/NVIDIA/gpu-operator/issues/430#issuecomment-1531041346

해결 과정

Docker와 Kubernetes에서의 해결과정은 차이가 있고 문제를 경험하며 애먹었던 것과 달리 해결하는 방법은 컨테이너 cgroup을 systemd가 관리하지 않도록 하고(위임 모델 회피), 런타임이 cgroupfs로 직접 관리하도록 다음과 같이 수월합니다.

 

Docker

1. docker restart container
   • 이를 통해 임시적으로 해결이 가능하지만 이렇게는 해결하지 않기를 권장합니다.
2. cgroupfs가 cgroup을 관리하도록 설정하기

# /etc/docker/daemon.json

{
  "exec-opts": ["native.cgroupdriver=cgroupfs"]
}

# 추가했다면 systemctl restart docker로 적용

 

kubernetes

• Gpu Operator v22.9.2 이상의 버전을 사용하기
• helm 같은 경우 compatWithCPUManager=true 옵션으로 우회하기

위 과정들을 진행했다면 Docker, Kubernetes환경에선 더 이상 위와 같은 이슈로 나오는 NVML 없이 GPU 워크로드에서 엔진이 안정적으로 돌 수 있는 환경을 갖출 수 있게 됩니다.

부록

WSL에선 왜 cgroupfs가 아니라 systemd였나 하고 system로그를 확인한 결과 부팅 과정 중 cgroupfs로 넘어가려던 과정에서 장애가 발생하여 systemd로 있던 것을 확인할 수 있었습니다.

• WSL(장애 노드) 부팅/서비스 로그에서 추가로 관찰된 신호
  • System is tainted: cgroupsv1
  • Failed to migrate controller cgroups... Input/output error
  • containerd... loading plugin "io.containerd.monitor.v1.cgroups"...

driver의 문제임을 확인하고 나서 그럼 정말로 systemctl daemon-reload로 trigger가 될까?라고 확인해 볼 땐 매번 재현되는 것을 보며 드디어 1년 이상 괴롭혔던 것의 정확한 원인과 그에 따른 문제를 확인했구나라고 느꼈던 것도 같습니다.

 

또 노드가 자동 업데이트를 통해 업데이트가 된다면 모듈의 업데이트는 진행되지만 gpu driver는 업데이트가 진행돼도 재부팅이 되지 않아 버전의 충돌이 발생함으로 이것을 자동화하거나, 체크하거나, 버전을 고정하는 등의 방법이 필요한 것 같습니다.

 

•  

회고/재발 방지 포인트 

이 이슈를 확인해 보며 제가 설치한 Gpu Stack이나 라이브러리, 등의 문제가 아니라 리눅스의 cgroup을 관리하는 systemd vs cgroupfs 간의 차이가 이런 문제를 발생시킬 수 있다는 것을 보며 당연할 수 있지만 리눅스 시스템의 이해도가 문제 원인 추정, 파악과 해결에 지대한 영향을 줄 수 있다는 것을 다시 한번 느낄 수 있었던 것 같습니다.

 

다른 것들과 달리 재현하는 이유도 몰랐으며 어떻게 확인해야 하는지도 몰랐고 NVML에 관련된 다른 이슈를 해결했던 것처럼 커널과 리눅스 외 다른 것들부터 파악했었는데 관성적으로 접근했던 부분을 딥하게 확인하다 보니 리눅스의 격리 동작원리, 드라이버 등을 더 자세히 이해해 봐야겠다라고 생각이 든 것 같습니다.

 

Gpu 워크로드에서 NVML이슈가 발생한다면 전 앞으로 이런 과정으로 문제의 이슈를 확인하고 해결해 나갈 것 같습니다.

• GPU Stack 간 버전 차이가 없는지를 확인합니다.
• Cgroup Driver / Cgroup Version을 확인합니다.
• 관련된 리눅스의 드라이버, 동작원리, 라이브러리 등을 확인합니다.

 

이상 GPU 워크로드에서의 접근 권한 상실 Trouble Shutting에 대한 글을 마무리하며 이 글이 추후의 까먹을 저와 몰라서 이슈를 겪고 있는 분들에게 도움이 되었으면 좋겠습니다.