비용을 줄이려고 GPU 노드 풀을 g4dn 인스턴스에서 g5 인스턴스로 교체하는 작업을 어젯밤에 끝냈습니다. 옛 노드가 모두 빠진 뒤 오늘 아침 추론 서비스 새 버전을 배포했는데, 파드가 Pending에서 움직이지 않아 추천 기능이 이전 버전으로만 응답하고 있습니다. 새 GPU 노드 3대는 Ready이고 GPU·메모리 여유도 충분합니다. 온콜 담당자는 GPU가 부족하다며 노드 풀 크기를 두 배로 늘리려고 합니다. 노드 풀 교체 작업 계획서에는 '워크로드 영향 없음'이라고 적혀 있었습니다.
노드 풀을 교체한 뒤 GPU 추론 파드가 계속 Pending
비용을 줄이려고 GPU 노드 풀을 g4dn 인스턴스에서 g5 인스턴스로 교체하는 작업을 어젯밤에 끝냈습니다.
시나리오
단서
Warning FailedScheduling default-scheduler 0/5 nodes are available: 5 node(s) didn't match Pod's node affinity/selector. preemption: 0/5 nodes are available: 5 Preemption is not helpful for scheduling.
NAME STATUS INSTANCE-TYPE gpu-a1 Ready g5.xlarge gpu-a2 Ready g5.xlarge gpu-a3 Ready g5.xlarge app-b1 Ready m6i.large app-b2 Ready m6i.large
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: node.kubernetes.io/instance-type
operator: In
values: ["g4dn.xlarge"]과제 원인을 좁히고, 서비스를 되살리는 순서(검증 포함)와 재발 방지책을 적어 보세요.
구독하면 이어서 볼 수 있어요
이 문제의 전체 시나리오와 점검 체크리스트, 복구 순서, 모범 풀이는 Pro 구독에서 열립니다.
먼저 볼 것
- 스케줄러가 말하는 '못 올린 이유' 읽기
- 자원 부족과 배치 조건 불일치 구분하기
점검 체크리스트
- kubectl describe pod 의 FailedScheduling 메시지
- kubectl get nodes -L <affinity 키> 로 실제 노드 라벨 확인
- Deployment의 required 조건과 노드 라벨 비교
복구와 재발 방지
같이 보면 좋은 질문
현장에서 본 비슷한 케이스