测验：驱动不是应用程序，而是内核模块

미리 컴파일된 드라이버 이미지의 태그가 525-5.15.0-69-generic-ubuntu22.04 처럼 세 조각인 이유는?

• 커널 모듈은 커널 판에 맞춰 컴파일되므로 브랜치·커널판·OS 조합마다 다른 이미지가 필요하기 때문이다
• 레지스트리가 같은 브랜치의 이미지를 한 태그로 묶어 두면 풀 속도가 느려지기 때문이다
• 오퍼레이터가 태그를 파싱해 노드의 시간대와 지역을 정하고 미러 레지스트리를 고르기 때문이다
• CUDA 런타임 판과 드라이버 판을 한 태그에 함께 담아야 호환을 검증할 수 있기 때문이다

보안 패치로 노드 절반의 커널이 한 칸 올라갔고 그 조합의 드라이버 이미지는 아직 빌드하지 않았다. 어떻게 드러나는가?

• 오퍼레이터가 ClusterPolicy 를 Degraded 로 바꾸고 클러스터 전체의 GPU 스케줄링을 멈춘다
• 그 노드들에서만 드라이버 파드가 이미지를 받지 못해 죽고, 나머지 노드는 멀쩡해 클러스터 경보가 울리지 않는다
• 커널이 올라간 노드의 kubelet 이 NotReady 로 바뀌어 그 노드의 모든 파드가 퇴거된다
• 드라이버 파드가 예전 이미지로 계속 돌지만 커널 모듈만 내려가 nvidia.com/gpu capacity 가 0 이 된다

드라이버 판과 CUDA 런타임의 호환 방향을 바르게 말한 것은?

• 양방향으로 호환되지 않으므로 컨테이너의 CUDA 판과 노드의 드라이버 판이 정확히 같아야 한다
• 새 CUDA 컨테이너는 옛 드라이버에서 돌지만 옛 CUDA 컨테이너는 새 드라이버에서 돌지 않는다
• 옛 CUDA 컨테이너는 새 드라이버에서 돌지만 새 CUDA 컨테이너는 옛 드라이버에서 돌지 않는다
• 호환은 드라이버가 아니라 컨테이너 툴킷의 판이 정하므로 드라이버 판은 자유롭게 섞어도 된다

드라이버 업그레이드가 한 노드에서 오래 멈춰 있다. 가장 먼저 볼 곳은?

• 드라이버 컨테이너의 dmesg 출력 — 모듈 적재 실패는 커널 링 버퍼에만 남는다
• 노드의 컨테이너 런타임 설정 — 기본 런타임이 바뀌면 드라이버 파드만 다른 핸들러로 뜬다
• GFD 가 붙인 nvidia.com/gpu.product 라벨 — 모델이 바뀌면 업그레이드 대상에서 빠진다
• 노드의 nvidia.com/gpu-driver-upgrade-state 라벨 — 어느 단계에서 멈췄는지가 한 줄로 적혀 있다

kubectl drain 이 PodDisruptionBudget 때문에 거절당했다. 이때 노드의 상태는?

• drain 은 파드를 모두 비운 뒤에 cordon 하므로 노드는 아직 스케줄을 받을 수 있는 상태다
• eviction 이 한 번이라도 거절되면 drain 이 cordon 을 되돌리므로 노드는 원래대로 돌아간다
• drain 은 먼저 cordon 한 뒤 파드를 evict 하므로, 막혀도 노드는 이미 스케줄 불가 상태로 남는다
• PDB 위반이 감지되면 API 서버가 노드에 NoExecute 테인트를 걸어 나머지 파드도 함께 퇴거시킨다

업그레이드 정책의 drain.enable 이 기본값 꺼짐인 이유로 문서가 드는 근거는?

• 드레인은 GPU 와 무관한 워크로드까지 그 노드에서 모두 내쫓는 파괴적인 작업이기 때문이다
• 드레인은 노드 오브젝트를 지웠다가 다시 만들기 때문에 노드 라벨이 함께 사라지기 때문이다
• 드레인은 데몬셋 파드까지 퇴거시켜 드라이버 파드 자신이 먼저 사라지기 때문이다
• 드레인 중에는 eviction API 대신 강제 삭제가 쓰여 PodDisruptionBudget 이 무시되기 때문이다