도구보다 층을 먼저 부른다

한 줄 요약

GPU 를 누구에게 언제 줄 것인가는 한 도구의 일이 아니라 「다섯 층」의 일입니다. 장치를 알리는 층, 입장을 다스리는 층, 파드를 묶는 층, 노드를 고르는 층, 그 위에서 서비스를 짜는 층. 문제가 생기면 어느 층의 결정인지부터 가리면 답이 빨라지고, 문서와 다른 동작을 만나면 그 층의 프로젝트에 고쳐 보내면 됩니다.

왜 이게 필요했나

이 코스에서 본 사고는 거의 전부 「층이 다른 두 결정의 어긋남」 이었습니다. Kueue 는 쿼터로 입장시켰는데 노드에 자리가 없었습니다(입장 대 배치). LWS 는 그룹을 만들었는데 리더만 떴습니다(묶음 대 배치). fake-gpu-operator 의 풀 크기를 바꿨는데 노드 광고가 그대로였습니다(설정 대 장치). KAI 는 GPU 를 쪼갰는데 k3s 의 RuntimeClass 때문에 컨테이너가 뜨지 않았습니다(배치 대 런타임). 도구 이름으로 문제를 부르면 길을 잃고, 층으로 부르면 다음에 볼 곳이 보입니다.

어떻게 동작하나

층      묻는 질문                         이 코스의 도구                      어긋나면 보이는 것
장치    이 노드에 무엇이 몇 개 있나          장치 플러그인 · DRA 드라이버           allocatable 숫자, ResourceSlice
입장    지금 이 작업이 들어가도 되나          Kueue                              Workload 조건, suspend
묶음    어떤 파드들이 한 몸인가               JobSet · LeaderWorkerSet           restart-attempt, 그룹 번호
배치    어느 노드에, 함께 놓을 수 있나        kube-scheduler · KAI-Scheduler     PodScheduled 사유, PodGroup 조건
서빙    요청을 어디로, 몇 개로 나눠 받나       Dynamo(llm-d 등)                   DGD 상태, 라우터 지표

도구를 고르는 기준도 층에서 나옵니다. 기본 스케줄러를 그대로 두고 싶으면 입장 층(Kueue)만 더합니다. 갱 배치와 GPU 쪼개기, 위상 인식이 핵심이면 배치 층을 바꿉니다(KAI). 분산 학습은 묶음 층에 JobSet 을, 멀티 노드 추론은 LWS 를 두고, 묶음과 배치 사이의 틈(반쪽 실행)은 갱 스케줄러나 Kueue 의 한 덩어리 입장으로 메웁니다. 장치 층은 장치 플러그인에서 DRA 로 옮겨 가는 중이라, 새로 짓는 클러스터라면 DeviceClass 이름부터 정해 두는 편이 좋습니다.

현장에서 만나는 모습

이 코스를 만들며 실험 VM(4 vCPU·4GiB, k3s v1.36.5)에서 직접 부딪힌 것들을 층별로 다시 적습니다. 문서에 없거나 문서와 다른 것이라 그대로 기여 거리가 됩니다.

장치  fake-gpu-operator 를 k3s 에 기본값으로 깔면 RuntimeClass nvidia 소유권 충돌로 실패한다
장치  풀의 gpuCount 를 바꿔도 이미 등록된 노드는 바뀌지 않는다(토폴로지 ConfigMap 을 다시 만들지 않음)
배치  KAI 큐의 limit 을 비우면 0 으로 읽혀 quota 안의 GPU 도 받지 못한다
배치  fake-gpu-operator 의 예약 네임스페이스 기본값(runai-reservation)이 KAI 와 달라 쪼개기가 시간 초과
장치  dra-example-driver 의 README 는 공개 차트(registry.k8s.io)로 설치하는 길을 적지 않는다
입장  Kueue 가 먼저 떠 있으면 JobSet 을 나중에 깔았을 때 통합이 켜지기까지 약 1분이 걸린다(문서에 없음)
서빙  Dynamo 설치 문서는 nats-* 파드를 기대하지만, 1.6.0 차트 기본값은 NATS 를 깔지 않는다

고쳐 보내기 전에 프로젝트마다 다른 규칙을 확인하세요. 2026-10-27 에 각 저장소의 기여 문서를 확인한 내용입니다.

「kubernetes-sigs(Kueue·JobSet·LWS·dra-example-driver)」: 쿠버네티스 기여 안내의 AI 지침을 따릅니다. AI 를 썼다면 PR 설명에 밝혀야 하고, AI 가 쓴 커밋 메시지·AI 공동 저자 표기는 받지 않으며, 리뷰 답변은 사람이 직접 씁니다. 기여자 라이선스 동의(CLA)가 필요합니다.
「KAI-Scheduler」: CNCF 샌드박스로, DCO 서명(git commit -s)과 Conventional Commits 꼴의 PR 제목을 씁니다. 저장소에 따로 정한 AI 정책 문서는 확인하지 못했습니다.
「fake-gpu-operator」: PR 에 연결된 이슈가 있어야 검사를 통과합니다. 이슈를 먼저 엽니다.
「Dynamo·NVIDIA 저장소」: DCO 서명이 필요하고, Dynamo 는 서명된(Verified) 커밋이어야 자동 시험이 돕니다.

응답 속도도 다릅니다. 최근 30일 바깥 기여자 PR 의 첫 사람 응답까지 걸린 시간 중앙값을 세어 보니 Kueue 0.6시간, JobSet 1.8시간, LWS 3.7시간, KAI 약 20시간이었고, fake-gpu-operator 는 바깥 기여자 PR 열 건 가운데 한 건만 답을 받았습니다. 숫자는 그때의 표본이라 금방 바뀌지만, 「빨리 답하는 곳에서 첫 기여를 시작하라」 는 판단에는 충분합니다.

English corner

Name the layer before you name the tool.

이슈를 쓸 때도 같습니다. 「Kueue admitted the workload but the pod is Pending」 처럼 층과 관찰을 함께 적으면 메인테이너가 한 번에 알아듣습니다.

다음 퀴즈에서 확인할 것

증상을 듣고 어느 층의 결정인지 고르는 문제와, 기여할 때 프로젝트 규칙을 지키는 문제를 풉니다.