728x90
왜 K8s와 Slurm을 연계해야 하는가
전통적으로 HPC 환경은 Slurm과 같은 전용 스케줄러를 사용해 대규모 연산 Job을 관리해왔습니다.
반면, 최신 AI/ML 워크로드는 Kubernetes(K8s) 위에서 컨테이너 기반으로 배포되는 경우가 많습니다.
이 두 환경을 각각 따로 운영하면:
- 자원(CPU/GPU) 할당이 이중으로 관리됨 → 비효율 발생
- 사용자는 서로 다른 Job 제출 방식을 익혀야 함 → 학습 비용 증가
- 스토리지·네트워크·모니터링 중복 구성 → 운영 복잡성 증가
그래서 **K8s Batch Scheduler(Volcano, Kueue 등)**와 Slurm을 연계해 하이브리드 스케줄링을 구현하면, HPC와 클라우드 네이티브 워크로드를 하나의 자원 풀에서 유연하게 운영할 수 있습니다.
1. 연계 운영의 기본 아키텍처
[사용자] → [K8s API Server] → [Batch Scheduler(Volcano/Kueue)]
↓
[Slurm Adapter]
↓
[Slurm Controller]
↓
[Compute/GPU Nodes]
- Volcano/Kueue: K8s 상의 Job 큐잉 및 우선순위 관리
- Slurm Adapter: K8s Job 요청을 Slurm Job으로 변환
- Slurm Controller: HPC 자원 스케줄링 및 실행
- Compute/GPU Nodes: 실제 연산 수행
2. Volcano와 Kueue 개요
Volcano
- K8s 네이티브 배치 스케줄러
- Gang Scheduling, Fairshare, Queue 관리 지원
- 대규모 분산 Job, MPI, TensorFlow, PyTorch 워크로드에 적합
Kueue
- Kubernetes SIG Scheduling에서 개발
- Job Queue를 논리적으로 관리하며, 리소스 요청량에 따라 실행 순서 결정
- Slurm, HTCondor 등 외부 스케줄러와 연계하기 용이
3. Slurm 연계 방식
방법 1 – Slurm Operator
- Slurm을 Kubernetes CRD(Custom Resource Definition)로 정의
- SlurmJob 리소스를 생성하면 Operator가 Slurm에 Job 제출
- 장점: 네이티브 K8s API 사용
- 단점: Operator 설치·유지보수 필요
apiVersion: slurm.scheduling/v1
kind: SlurmJob
metadata:
name: gpu-train-job
spec:
nodes: 2
gpus: 8
time: "02:00:00"
script: |
module load cuda/12.2
srun python train.py
방법 2 – Volcano/Kueue + Slurm REST API
- Volcano/Kueue에서 Job을 큐에 넣고, Slurm REST API로 변환·전송
- 장점: Slurm 설치 환경 변경 최소화
- 단점: REST API 서버(slurmrestd) 보안·인증 설정 필요
방법 3 – 배치 게이트웨이(Pipeline)
- Airflow, Argo Workflows 등 파이프라인 엔진에서 K8s와 Slurm을 병렬로 호출
- 장점: 복잡한 워크플로우 조합 가능
- 단점: 실시간 스케줄링보다는 배치 중심
4. GPU 워크로드 연계 운영 시 고려사항
- GPU 자원 단일 뷰
- Slurm과 K8s에서 동일 GPU 자원 정보를 참조해야 함
- nvidia-device-plugin + Slurm GRES 설정 동기화 필요
- 네트워크/스토리지 통합
- InfiniBand, NVLink 등 HPC 네트워크를 K8s Pod에서도 접근 가능하게 구성
- 공용 병렬 파일시스템(Lustre, BeeGFS) 마운트
- 보안·권한 관리
- LDAP/AD 기반 사용자 인증 통합
- K8s 네임스페이스와 Slurm 계정(Account) 매핑
5. 운영 시나리오 예시
| 시나리오 | 처리 방식 |
| AI 학습 서비스는 K8s, 대규모 모델 학습은 Slurm | K8s Job → Volcano 큐 → Slurm Adapter 제출 |
| Slurm에서 실행 중인 Job 상태를 K8s에서 모니터링 | Slurm REST API → K8s Custom Controller |
| GPU 노드 자원 공용화 | Slurm GRES + K8s Node GPU Label 동기화 |
6. 장점과 단점
장점
- HPC와 클라우드 네이티브 환경 통합
- 자원 활용률 극대화
- 사용자 경험 일원화 (단일 Job 제출 인터페이스 가능)
단점
- 연계 구성 복잡도 높음
- 장애 시 양쪽 스케줄러 동시 영향 가능
- 운영팀의 Slurm + K8s 복합 역량 필요
7. 실무 팁
- PoC 단계에서는 Volcano와 Slurm 연계부터 시작, 이후 Kueue 도입 검토
- Slurm QoS/Fairshare 정책을 K8s Queue Priority와 맞춤
- GPU 사용량 메트릭은 Prometheus + DCGM Exporter로 양쪽 환경에서 공통 수집
정리하며
K8s Batch Scheduler(Volcano/Kueue)와 Slurm 연계는 HPC와 클라우드 네이티브 환경의 장점을 모두 살리는 전략입니다.
운영자는 두 스케줄러의 정책을 일관성 있게 구성하고, 자원·스토리지·보안 통합을 통해 사용자 경험과 자원 효율을 동시에 높일 수 있습니다.
다음 23편에서는 Slurm 트러블슈팅 – Pending·Fail 상태 원인 분석과 해결을 다뤄, 스케줄링 장애 상황에서의 문제 해결력을 높이겠습니다.
728x90