Quiz: Runtime Registration and Config Merge

드롭인 파일에는 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 와 같은 값으로 비교하는 것
• 점검을 노드가 뜰 때마다 자동으로 실행하는 것
• 설정 파일을 직접 읽어 핸들러 유무를 판정하는 것