TT Lab
요금제

한국어

시작하기
블로그

블로그

자동 갱신이 GPU 를 멈춘 날: 라이브러리는 새 판, 커널 모듈은 옛 판

상태: 해결 (2026-10-13 ~ 14), 기록 기준. 갱신 시각과 패키지 목록은 2026-10-16 에 노드의 unattended-upgrades.log 를 읽어 확인했고, 그날의 오류 문구는 작업 메모에서 가져왔습니다. 파드 오류가 왜 그 모양이었는지는 추정입니다. 드라이버의 정확한 판 번호는 노드와 짝지어지므로 적지 않습니다.

목차

한 줄 요약

영향 GPU 노드 하나에서 GPU 를 요청한 파드가 시작 실패. 그 노드의 GPU 실험이 사흘 동안 조용히 막혀 있었다
원인 unattended-upgrades 가 NVIDIA 드라이버 패키지를 올렸고, 적재된 커널 모듈은 재부팅 전까지 옛 판 → 사용자 라이브러리와 판이 어긋남
고친 것 노드 재부팅(새 모듈 적재). 사람이 했다 — 같은 노드의 다른 서비스가 잠시 끊기기 때문
재발 방지 GPU 노드의 자동 갱신에서 NVIDIA 패키지를 뺐다(Package-Blacklist). 드라이버는 계획해서 올린다

1. 증상: 원인을 가리키지 않는 오류

GPU 를 요청한 파드가 컨테이너를 만들지 못했고, 이벤트의 오류는 이렇게 끝났습니다.

… open /run/nvidia-persistenced/socket: no such file or directory

파드 오류만 보면 GPU Operator 나 컨테이너 툴킷, 혹은 persistenced 데몬 설정을 먼저 의심하게 됩니다. 실제로 그 노드의 nvidia-persistenced 는 떠 있지 않았습니다. 하지만 그것은 결과였습니다. 노드에서 직접 물어보니 진짜 답이 나왔습니다.

$ nvidia-smi
Failed to initialize NVML: Driver/library version mismatch

파드 오류가 왜 하필 소켓 이야기였는지는 확인하지 못했습니다. 추정은 이렇습니다. 판이 어긋나 NVML 이 초기화되지 않으니 persistenced 가 뜨지 못하고 소켓도 생기지 않는데, 컨테이너에 GPU 를 붙이는 쪽은 그 소켓이 있다고 보고 열려다 실패했다는 것입니다. 교훈은 분명합니다. GPU 파드가 이상하면 먼저 노드에서 nvidia-smi 를 친다.

2. 원인: 사흘 전 새벽의 자동 갱신

노드의 unattended-upgrades.log 에 답이 있었습니다. 2026-10-10 06:08, 자동 갱신이 올릴 패키지 목록에 NVIDIA 관련 패키지 15개가 들어 있었습니다 — 사용자 라이브러리(libnvidia-*), 유틸리티, 드라이버 메타 패키지, 그리고 커널 모듈 소스와 dkms 패키지입니다.

디스크는 새 판, 메모리는 옛 판 디스크(설치된 것) 메모리(돌고 있는 것) 사용자 라이브러리 새 판(자동 갱신) nvidia-smi 가 여는 것 새 판(새로 열 때마다) 커널 모듈 파일 새 판(dkms 가 빌드) 적재된 커널 모듈 옛 판(재부팅 전까지) 둘이 만나면: Driver/library version mismatch 시간선 10-10 06:08 자동 갱신 (조용한 사흘) GPU 를 안 쓰면 10-13 GPU 파드 실패 10-13·14 두 노드 재부팅 재발 방지: 드라이버 패키지를 자동 갱신에서 빼고, 올릴 때는 비우기 → 올리기 → 재부팅 → 확인을 한 번에.
그림: 디스크와 메모리의 판이 갈라지는 구조와 시간선

여기서 판이 둘로 갈라집니다.

그런데 nvidia-smi 나 GPU 를 쓰는 프로세스는 시작할 때마다 디스크의 새 라이브러리를 엽니다. 새 라이브러리가 옛 모듈을 만나니 판이 맞지 않는다고 거절합니다.

왜 재부팅이 따라오지 않았을까요. unattended-upgrades 의 Automatic-Reboot 는 기본이 꺼짐입니다(공식 README 기준). 그 노드의 설정도 주석 처리된 기본값 그대로였습니다. 갱신은 자동, 재부팅은 수동 — 이 기본값 조합이 「반쯤 올라간」 상태를 만듭니다.

그리고 사흘 동안 아무도 몰랐습니다. 그 사이 그 노드에서 GPU 를 새로 잡은 파드가 없었기 때문입니다. 이미 GPU 를 쥐고 돌던 프로세스는 예전에 연 라이브러리를 계속 쓰므로 멀쩡해 보입니다(추정 — 그 사흘 동안 GPU 를 쥔 프로세스가 있었는지는 미확인).

3. 확인하는 법

# 적재된 모듈의 판
cat /proc/driver/nvidia/version
# 디스크에 깔린 패키지의 판
dpkg -l | grep -E 'nvidia-(driver|utils)-'
# 언제 누가 올렸나
grep -i nvidia /var/log/unattended-upgrades/unattended-upgrades.log
# 노드가 언제부터 켜져 있었나
uptime -s

첫째와 둘째의 판이 다르고, 셋째에 갱신 기록이 있고, 넷째가 그보다 이르면 이 사고입니다.

4. 고친 것: 재부팅, 그리고 그것은 사람 몫

새 모듈을 올리는 가장 확실한 방법은 재부팅입니다. 모듈만 내렸다 올리는 방법도 있지만, GPU 를 쥔 프로세스가 하나라도 있으면 내려가지 않습니다.

이 재부팅은 사람이 했습니다. 그 노드에는 GPU 파드만 있는 게 아니라 다른 운영 서비스 여러 개와 실험용 VM 이 함께 있었습니다. 재부팅하면 이것들이 잠시 끊기거나 다른 노드로 옮겨 갑니다. 그 시각과 영향은 사람이 정할 일입니다. 에이전트는 원인과 명령, 영향 목록을 정리해 넘겼습니다.

2026-10-13 에 그 노드를, 2026-10-14 에 같은 자동 갱신을 받은 다른 GPU 노드 하나를 재부팅해 두 노드의 모듈과 라이브러리 판을 맞췄습니다.

5. 재발 방지: 자동 갱신에서 드라이버 빼기

두 노드 모두 이렇게 넣었습니다(2026-10-16 에 파일을 읽어 확인).

// /etc/apt/apt.conf.d/51-no-nvidia-autoupgrade
Unattended-Upgrade::Package-Blacklist {
  "nvidia-";
  "libnvidia-";
  "xserver-xorg-video-nvidia";
};

Package-Blacklist 의 항목은 정규식입니다. 목록에 걸리는 패키지는 올리지 않고, 걸리는 패키지에 기대는 패키지도 함께 올리지 않습니다(공식 README 기준). 같은 일을 apt-mark hold 로 해도 됩니다. hold 는 수동 apt upgrade 까지 막는다는 점이 다릅니다.

대가도 적어 둡니다. 이제 드라이버의 보안 갱신도 자동으로 오지 않습니다. 그래서 드라이버는 계획해서 올립니다.

  1. 노드를 비운다(kubectl drain).
  2. 드라이버 패키지를 올린다.
  3. 재부팅한다.
  4. nvidia-smi 와 GPU 파드 하나로 확인하고 노드를 되돌린다(kubectl uncordon).

NVIDIA GPU Operator 문서의 플랫폼 지원 표에는 「지원하지 않는 커널로 올라가지 않게 unattended-upgrades 의 커널 자동 갱신을 끄라」는 권고가 이미 있습니다. 미리 깔아 둔 드라이버(driver.enabled=false)를 쓰는 경우 드라이버 패키지도 같은 일을 겪는다는 내용은 없어서, 문제 해결 문서에 이 사례를 더하는 PR 을 보냈습니다 — NVIDIA/cloud-native-docs#524(2026-10-16 기준 열려 있음).

6. 남은 것과 한계

티티 한마디. 자동 갱신은 반만 자동이에요. 파일은 바꿔 주지만 메모리는 재부팅해야 바뀌거든요. 그리고 파드가 엉뚱한 파일이 없다고 하면, 그 파일을 찾기 전에 노드에서 nvidia-smi 한 번! 진짜 이유는 대개 거기 있어요.

참고

모든 자료는 2026-10-16 에 열람했습니다.

로그인하면 좋아요를 누를 수 있습니다

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다