- Authors
- Name
문제 정의
GPU 스케줄링과 버전 업그레이드는 각각 별개처럼 보이지만, 실제로는 노드풀/런타임/드라이버/보안정책이 얽힌 단일 운영 문제다.
아키텍처/원리
- RuntimeClass로 컨테이너 런타임 특성을 분리하고, GPU 리소스는 device plugin으로 선언한다.
- 업그레이드는 control plane→node pool 순서와 버전 skew 규칙 준수가 핵심.
- admission policy로 위험한 워크로드를 사전 차단한다.
구현 예시 1
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
name: nvidia
handler: nvidia
구현 예시 2
def can_schedule_gpu(node_labels, request_gpu=True):
return request_gpu and node_labels.get("accelerator")=="nvidia"
구현 예시 3
SELECT node, avg(gpu_util) util, avg(pod_pending_sec) pending
FROM gpu_cluster_metrics
GROUP BY node ORDER BY pending DESC;
구현 예시 4
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: block-privileged-gpu
spec:
validationFailureAction: Enforce
rules:
- name: disallow-privileged
validate:
message: 'privileged 금지'
pattern:
spec:
containers:
- =(securityContext):
=(privileged): false
운영 팁
- GPU 노드는 전용 node pool로 분리하고 일반 워크로드와 혼합하지 않는다.
- 업그레이드 전후 conformance + 대표 모델 추론 테스트를 묶는다.
- MIG 사용 시 리소스 단위를 팀별 계약으로 문서화한다.
트러블슈팅
- Pending 지속: taint/toleration과 resource request 불일치 확인.
- 업그레이드 후 CNI 오류: addon 버전 호환성 재검증.
- GPU util 저조: 배치 크기/동시성 자동튜닝 적용.
체크리스트
- RuntimeClass/DevicePlugin 상태 확인
- 버전 skew 검증
- GPU 노드 격리 정책
- 업그레이드 리허설
- 롤백 이미지 준비
결론
Kubernetes GPU 운영은 스케줄링 튜닝보다 “버전·런타임·정책 호환성”을 체계적으로 관리하는 일이 핵심이다.