무엇이 실물이고 무엇이 흉내인가

한 줄 요약

이 실습 파드에는 진짜 GPU 도, 진짜 containerd 도, GPU Operator 도 없다. 대신 TOML 파서와 진짜 쿠버네티스 컨트롤 플레인이 있고, 이번 사고에서 사람을 잡은 것들은 거의 전부 그 둘로 재현된다.

왜 가짜 환경에서 이걸 하나

GPU 사고에서 실제로 배워야 하는 것을 하나씩 세어 보면 이렇다.

• 설정 파일 두 개가 같은 테이블을 두고 부딪히는지 판정하는 법 → 파서면 된다
• 파일이 아니라 로드된 것을 보는 점검 스크립트를 쓰는 법 → 셸이면 된다
• 자원 광고가 없으면 파드가 어디서 막히는지 → 스케줄러가 진짜여야 한다
• 타임슬라이싱 설정에서 슬롯 수와 메모리를 계산하는 법 → 산수면 된다
• 롤아웃이 한 노드에서 멈춘 모양 → 데몬셋 컨트롤러가 진짜여야 한다

이 목록에 nvidia-smi 는 없다. GPU 장치를 실제로 만져야만 배울 수 있는 것은 드라이버 빌드와 실제 커널 실행 성능인데, 그 둘은 이번 사고의 원인이 아니었다. 원인은 전부 설정과 오브젝트에 있었다.

무엇이 진짜로 검증되고 무엇이 흉내인가

| 실습에서 하는 것 | 이 환경에서의 지위 |
| --- | --- |
| containerd 설정을 TOML 로 쓰고 파싱 | 실물. 진짜 파서가 읽는다 |
| 주 설정과 드롭인의 테이블 충돌 판정 | 실물. 계산이 그대로 맞다 |
| 점검 스크립트 동작 검증 | 실물. 가짜 containerd 를 세워 두 번 실제로 돌린다 |
| RuntimeClass 등록 | 실물. 진짜 API 서버가 저장한다 |
| GPU 자원 광고와 스케줄링 | 실물. 진짜 스케줄러가 판정한다 |
| 데몬셋 롤링 업데이트 정지 | 실물. 진짜 컨트롤러가 멈춘다 |
| 노드에 GPU 가 실제로 꽂혀 있는 것 | 흉내. 노드 status 에 숫자만 적는다 |
| 컨테이너 안에서 GPU 를 쓰는 것 | 없음. 컨테이너가 실행되지 않는다 |
| containerd 를 재시작해 핸들러가 등록되는 것 | 없음. 개념과 점검 스크립트로만 다룬다 |

특히 마지막 줄을 분명히 해 두자. SIGHUP 으로는 안 되고 재시작해야 한다는 사실은 이 파드에서 실증할 수 없다. 그래서 실습은 그 대신 "재시작 여부와 무관하게 진실을 알려 주는 점검 스크립트" 를 만들게 한다. 현장에서 그 지식이 손으로 나오는 자리가 바로 그 스크립트다.

현장에서 그대로 쓰이는 것

실습에서 만드는 산출물 중 셋은 그대로 회사에 가져갈 수 있다.

• check-runtime.sh — 노드 부팅 후 점검이나 CI 게이트에 그대로 건다. 판정 기준이 파일이 아니라 dump 라는 것이 핵심이고, 그 성질은 환경과 무관하다.
• 슬롯 계산표 — 타임슬라이싱을 켜기 전에 사용자에게 보여 줄 표다. "자리는 20개, 보장 메모리는 0" 이라는 두 줄이 대화의 절반을 끝낸다.
• 롤아웃 정지 보고서 — 어느 칸을 보고 무엇을 판단했는지가 남는다. 사고 보고서의 뼈대가 이것이다.

다음 실습에서 할 것

여덟 단계로 사고를 처음부터 다시 밟는다. 앞의 네 단계는 노드의 설정 파일을 다루고, 뒤의 네 단계는 클러스터 오브젝트를 다룬다. 마지막 두 단계는 앞에서 만든 것을 모아 계산과 보고로 끝낸다.