测验: 把 GPU 故障分成不同分支

GPU 파드가 안 뜬다는 신고를 받았다. 원인을 좁히기 위해 가장 먼저 확인할 것은?

• 파드 오브젝트가 존재하는지 — 어드미션에서 거부되면 파드 자체가 생기지 않아 스케줄러는 무관하다
• device plugin 데몬셋 파드의 로그 — GPU 자원 광고는 전부 이 로그에 이유가 남는다
• 노드의 nvidia-smi 출력 — 카드가 물리적으로 붙어 있는지가 모든 판정의 출발점이다
• containerd 설정에 nvidia 런타임 핸들러가 등록돼 있는지 — 없으면 어떤 GPU 파드도 뜨지 않는다

Insufficient nvidia.com/gpu 라는 스케줄러 메시지만으로 판정하면 안 되는 이유는?

• 이 메시지는 확장 자원이 아니라 cpu·memory 가 모자랄 때만 나오므로 GPU 장애와 무관하다
• 자원 미광고·allocatable 0·자리 소진 세 가지가 모두 같은 문장을 내고, 각각 조치가 다르다
• 스케줄러는 실패 사유를 30초만 보관하므로 그 뒤에는 메시지 자체가 신뢰할 수 없게 된다
• 이 메시지는 노드가 아니라 네임스페이스 쿼터의 잔여량을 뜻해서 노드 상태와 상관이 없다

판정을 nodeSelector → 테인트 → capacity → allocatable → 남은 자리 순서로 해야 하는 이유는?

• 스케줄러가 실제로 그 순서로 필터를 돌리고 중간에 실패하면 남은 필터의 결과를 status 에 적기 때문이다
• 앞 단계일수록 확인이 빠른 명령이라 전체 조사 시간이 짧아지고 API 서버 부하도 줄기 때문이다
• 앞 단계가 참이면 뒤 단계는 검사 대상 자체가 없어, 순서를 어기면 멀쩡한 설정을 고치게 되기 때문이다
• 쿠버네티스가 이 순서를 공식 문제 해결 절차로 정해 두어 다른 순서는 지원 대상이 아니기 때문이다

어떤 노드가 GPU 를 쓸 수 있는지 스케줄러가 판단하는 유일한 근거는?

• 노드에서 실행한 nvidia-smi 가 장치를 몇 개 보고하는가
• 노드의 containerd 설정에 nvidia 런타임 핸들러가 등록돼 있는가
• GPU Feature Discovery 가 붙인 nvidia.com/gpu.count 라벨의 값이 얼마인가
• 노드 오브젝트 status 의 capacity 와 allocatable 에 적힌 확장 자원 숫자

'자리 소진' 을 판정할 때 노드 오브젝트만으로는 부족하고 파드 목록까지 합산해야 하는데, 합산에서 반드시 제외해야 하는 것은?

• GPU 를 두 개 이상 요구하는 파드 — 확장 자원은 정수 하나만 요청할 수 있어 잘못된 항목이다
• 다른 네임스페이스의 파드 — 확장 자원 회계는 네임스페이스 단위로 따로 이뤄진다
• DaemonSet 이 만든 파드 — 데몬셋 파드는 스케줄러를 거치지 않아 자원 회계에 들어가지 않는다
• phase 가 Succeeded 나 Failed 인 파드 — 끝난 파드는 자리를 쥐고 있지 않다

장애 분류기의 출력을 문장이 아니라 allocatable-zero 같은 한 단어로 정하는 실질적인 이득은?

• 출력이 짧을수록 kubectl 의 응답이 빨라져 60초 안에 판정을 끝낼 수 있다
• 다음 행동이 하나로 정해지는 어휘가 되어 알림 라우팅 키로 그대로 쓸 수 있다
• 쿠버네티스가 정한 표준 사유 코드라서 이벤트의 reason 필드와 자동으로 맞춰진다
• 한 단어는 번역이 필요 없어 다국어 운영팀에서 오해가 생기지 않는다