GPU Operator 와 타임슬라이싱 · 한 장을 여럿이 쓴다는 말의 뜻 · 실습
나눠 쓰기 설정 — 슬라이스·MIG·쿼터로 갈라 놓기
목표
한 장을 여럿이 쓰게 만드는 세 가지 방식을 설정과 오브젝트로 다룹니다.
슬라이스 수만큼 자리가 늘어나는 것을 노드 status 로 확인하고, MIG 노드는 자원
이름 자체가 다르다는 것을 스케줄링으로 확인하고, 팀에게 나눠 준 몫을 쿼터로
못 박는 데까지 갑니다.
왜 중요한가
GPU 는 사고 나면 사용률이 하루 평균 한 자리인데 대기열은 늘 차 있습니다. 파드
하나가 카드 한 장을 통째로 잡기 때문입니다. 여기서 "한 장을 여럿이 쓰게 해
달라" 는 요구가 나오고, 답이 셋인데 이름이 비슷해 자주 섞입니다.
가장 중요한 구분은 무엇을 나누는가 입니다. 타임슬라이싱의 replicas 는 GPU 를
조각내라는 뜻이 아니라 같은 장치를 여러 번 등록하라는 뜻입니다. 자리는 늘어나지만
VRAM 은 나뉘지 않은 한 덩어리라, 한 파드가 많이 잡으면 나머지가 메모리 부족을
맞습니다. MPS 는 커널을 동시에 실행시켜 처리량을 올리지만 격리는 여전히 약합니다.
MIG 만이 하드웨어에서 나누므로 메모리도 오류도 격리됩니다. 그리고 MIG 노드는
자원 이름 자체가 프로파일 이름으로 바뀌어서, 옛 매니페스트가 그 노드를 영영 못
쓰는 일이 생깁니다.
환경
이 파드에는 GPU 도 장치 플러그인도 없습니다. 대신 kwok 이 띄운 진짜 컨트롤
플레인이 있어서, 노드 status 에 숫자를 적으면 진짜 스케줄러가 그것을 보고
판정합니다. 쿼터도 진짜 apiserver 가 검사합니다. 작업 디렉터리는 /root/gpushare
이고 그 아래 k8s/·bin/·out/ 을 씁니다.
단계
1. gpu-share·team-a 네임스페이스와 설정 두 벌을 담은 ConfigMap 을 만듭니다.
2. 노드 라벨로 설정을 고르고 광고량을 각각 적습니다.
3. lab-node-2 를 MIG mixed 노드로 만듭니다.
4. 자원 이름만 다른 파드 둘을 띄워 갈리는 것을 봅니다.
5. team-a 에 쿼터를 걸고 넘치는 요청이 거절되는 것을 out/quota-denied.txt 에 담습니다.
6. bin/check-request.sh 로 슬라이스 여러 개 요청을 미리 거릅니다.
7. ConfigMap 에 mps 를 더하고 out/isolation.txt 에 격리 표를 적습니다.
8. 세 워크로드를 각자 맞는 노드에 놓고 out/placement.txt 에 적습니다.
참고
- 2단계의 광고량은 짐작하지 말고 1단계의
replicas를 곱해 넣으세요. 채점기가 capacity와allocatable을 함께 적어야 합니다. 한쪽만 적으면 스케줄러가- 3단계에서 MIG 노드에
nvidia.com/gpu를 함께 적지 마세요. mixed 전략의 핵심이 - 8단계의 노드 이름은
kubectl get pod -o wide로 확인해 적으세요.
ConfigMap 을 읽어 같은 곱셈을 다시 합니다.
쓸 자리가 생기지 않습니다.
그 노드가 프로파일 이름으로만 광고한다는 데 있습니다.
단계 8개
- 장치 플러그인 설정을 이름 붙여 두 벌 담는다
- 노드 라벨로 어느 설정을 쓸지 고른다
- MIG mixed 노드는 자원 이름 자체가 다르다
- 자원 이름이 다르면 서로의 자리에 못 간다
- 팀에게 나눠 준 몫을 쿼터로 못 박는다
- 슬라이스를 여러 개 달라는 요청을 배포 전에 거른다
- 세 번째 방식을 더하고 격리 표를 만든다
- 성격이 다른 세 워크로드를 각자 맞는 노드에 놓는다