퀴즈: GPU 스택의 구조

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

1. GPU Operator 를 도입해서 실제로 얻는 것은 무엇인가?

   1. 노드마다 갈라지던 설치 절차가 선언 한 장으로 수렴한다
   2. GPU 연산 자체가 커널 우회 경로로 빨라진다
   3. 여러 파드가 GPU 한 장을 안전하게 격리해 쓴다
   4. 드라이버 버전과 CUDA 버전 제약이 사라진다

2. 파드가 계속 Pending 이고 노드에 배정조차 되지 않는다면 먼저 볼 곳은?

   1. 노드 containerd 설정의 runtimes 테이블
   2. 노드 status 의 nvidia.com/gpu 광고량과 테인트
   3. 컨테이너 이미지의 CUDA 버전과 태그
   4. RuntimeClass 오브젝트의 handler 문자열

3. RuntimeClass 의 handler 에 오타를 내고 apply 하면 어떻게 되는가?

   1. API 서버가 등록된 핸들러 목록과 대조해 거부한다
   2. kubelet 이 기본 런타임으로 조용히 대체해 실행한다
   3. apply 는 통과하고 파드 생성 시점에 그 노드에서만 실패한다
   4. 노드가 NotReady 로 바뀌며 데몬셋이 재적용을 시도한다

4. 확장 자원인 nvidia.com/gpu 를 파드에 적을 때의 규칙은?

   1. requests 에만 적고 limits 는 비워 두어야 한다
   2. requests 와 limits 를 다르게 주어 버스팅을 허용한다
   3. 소수점으로 적어 GPU 를 분할 요청할 수 있다
   4. limits 에 정수로 적고 requests 는 같은 값이 된다

5. GPU Operator 의 toolkit 데몬셋이 다른 데몬셋과 결정적으로 다른 점은?

   1. 클러스터 오브젝트가 아니라 노드의 파일시스템을 고친다
   2. 네임스페이스가 아니라 클러스터 스코프로 배포된다
   3. 다른 데몬셋과 달리 노드 라벨을 전혀 보지 않는다
   4. 파드가 아니라 정적 매니페스트로 kubelet 이 띄운다

6. GPU 노드에 nvidia.com/gpu 테인트를 걸어 두는 이유는?

   1. device plugin 이 자원을 광고할 시간을 벌기 위해
   2. GPU 를 쓰지 않는 워크로드가 비싼 노드를 차지하지 못하게
   3. 드라이버 재적재 중 컨테이너 생성을 막기 위해
   4. 노드 업그레이드 순서를 스케줄러에 알려 주기 위해