LabHub

GPU Operator 와 타임슬라이싱 · 런타임 등록이 조용히 실패하는 자리 · 퀴즈

퀴즈: 런타임 등록과 설정 병합

LabHub 에서 이어서 보기

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

  1. 드롭인 파일에는 nvidia 런타임이 적혀 있는데 파드가 런타임 오류로 죽는다. 가장 먼저 확인할 것은?

    1. 드롭인 파일의 소유자와 파일 권한
    2. toolkit 데몬셋 파드의 재시작 횟수
    3. containerd config dump 로 로드된 핸들러 목록
    4. 노드에 설치된 nvidia 드라이버의 버전 문자열
  2. toolkit 이 설정을 쓰고 SIGHUP 을 보냈는데도 런타임 핸들러가 등록되지 않는 이유는?

    1. SIGHUP 이 설정 파일의 문법 오류 때문에 무시되기 때문
    2. SIGHUP 신호가 컨테이너 안에서는 호스트로 전달되지 않기 때문
    3. 리로드가 드롭인 디렉터리를 다시 읽지 않도록 막혀 있기 때문
    4. CRI 플러그인이 런타임 목록을 초기화 시점에만 읽기 때문
  3. GPU 설정을 복구할 때 올바른 순서는?

    1. toolkit 이 설정을 다시 쓰게 한 뒤 containerd 를 재시작한다
    2. containerd 를 재시작한 뒤 toolkit 파드를 삭제해 재생성한다
    3. toolkit 파드를 삭제하고 곧바로 containerd 를 재시작한다
    4. 노드를 재부팅한 다음 드롭인 파일을 손으로 다시 만든다
  4. 런타임 설정이 깨졌는데도 한동안 아무 증상이 없는 이유는?

    1. kubelet 이 설정 캐시를 주기적으로 갱신해 주기 때문
    2. 이미 실행 중인 컨테이너는 핸들러를 다시 조회하지 않기 때문
    3. device plugin 이 광고를 유지해 스케줄링이 계속되기 때문
    4. 드라이버 데몬셋이 런타임 오류를 자동으로 복구하기 때문
  5. imports 로 지정한 글롭이 실제 파일 이름과 어긋나면 containerd 는?

    1. 기동을 거부하고 설정 오류를 로그에 남긴다
    2. 가장 비슷한 이름의 파일을 대신 읽어 들인다
    3. 아무 경고 없이 그 파일을 읽지 않고 넘어간다
    4. 드롭인 디렉터리 전체를 통째로 다시 스캔한다
  6. 노드 부팅 후 점검 스크립트를 쓸 때 반드시 피해야 하는 것은?

    1. 실패했을 때 0 이 아닌 종료 코드로 끝내는 것
    2. 핸들러 이름을 RuntimeClass 와 같은 값으로 비교하는 것
    3. 점검을 노드가 뜰 때마다 자동으로 실행하는 것
    4. 설정 파일을 직접 읽어 핸들러 유무를 판정하는 것