GPU Operator 와 타임슬라이싱 · 런타임 등록이 조용히 실패하는 자리 · 퀴즈
퀴즈: 런타임 등록과 설정 병합
문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
드롭인 파일에는 nvidia 런타임이 적혀 있는데 파드가 런타임 오류로 죽는다. 가장 먼저 확인할 것은?
- 드롭인 파일의 소유자와 파일 권한
- toolkit 데몬셋 파드의 재시작 횟수
- containerd config dump 로 로드된 핸들러 목록
- 노드에 설치된 nvidia 드라이버의 버전 문자열
toolkit 이 설정을 쓰고 SIGHUP 을 보냈는데도 런타임 핸들러가 등록되지 않는 이유는?
- SIGHUP 이 설정 파일의 문법 오류 때문에 무시되기 때문
- SIGHUP 신호가 컨테이너 안에서는 호스트로 전달되지 않기 때문
- 리로드가 드롭인 디렉터리를 다시 읽지 않도록 막혀 있기 때문
- CRI 플러그인이 런타임 목록을 초기화 시점에만 읽기 때문
GPU 설정을 복구할 때 올바른 순서는?
- toolkit 이 설정을 다시 쓰게 한 뒤 containerd 를 재시작한다
- containerd 를 재시작한 뒤 toolkit 파드를 삭제해 재생성한다
- toolkit 파드를 삭제하고 곧바로 containerd 를 재시작한다
- 노드를 재부팅한 다음 드롭인 파일을 손으로 다시 만든다
런타임 설정이 깨졌는데도 한동안 아무 증상이 없는 이유는?
- kubelet 이 설정 캐시를 주기적으로 갱신해 주기 때문
- 이미 실행 중인 컨테이너는 핸들러를 다시 조회하지 않기 때문
- device plugin 이 광고를 유지해 스케줄링이 계속되기 때문
- 드라이버 데몬셋이 런타임 오류를 자동으로 복구하기 때문
imports 로 지정한 글롭이 실제 파일 이름과 어긋나면 containerd 는?
- 기동을 거부하고 설정 오류를 로그에 남긴다
- 가장 비슷한 이름의 파일을 대신 읽어 들인다
- 아무 경고 없이 그 파일을 읽지 않고 넘어간다
- 드롭인 디렉터리 전체를 통째로 다시 스캔한다
노드 부팅 후 점검 스크립트를 쓸 때 반드시 피해야 하는 것은?
- 실패했을 때 0 이 아닌 종료 코드로 끝내는 것
- 핸들러 이름을 RuntimeClass 와 같은 값으로 비교하는 것
- 점검을 노드가 뜰 때마다 자동으로 실행하는 것
- 설정 파일을 직접 읽어 핸들러 유무를 판정하는 것