korean-docs
Wave Diagnosis
Pod 스케줄링 지연

Pod Scheduling Delay Detection

Pending 상태에 머물러 있는 Pod는 아직 일어나지 않은 배포입니다. Pod Scheduling Delay Detection은 예상보다 오래 스케줄링을 기다린 모든 Pod와, 얼마나 기다렸는지, 그 뒤에 있는 정확한 스케줄러 조건을 추적합니다. 그래서 원시 이벤트를 읽지 않고도 진짜 용량 부족과 잘못 설정된 pod spec을 구분할 수 있습니다. 워크로드 단위로, 실시간으로 동작하며, 별도의 워밍업 기간이 필요 없습니다.

사이드바에서 Wave Diagnosis 아래 Scheduling Delays를 여세요. 클러스터 선택기와 날짜 범위 선택기(기본값 최근 7일)가 차트와 테이블의 범위를 정하고, 발견 배너와 KPI 카드는 최근 24시간을 요약합니다.

Scheduling Delays 페이지

Scheduling Delays page with the finding banner, KPI cards, Average Pending Time by Hour chart, and the delays table

발견 배너. "Pod가 왜 Pending에 멈춰 있는가?"에 대한 한 줄 답변으로, 최근 24시간 동안 몇 개의 Pod가 얼마나 기다렸는지를 보여줍니다.

KPI 카드. 네 개의 숫자가 문제의 규모를 한눈에 보여줍니다.

  • Total Delays: 범위 내에서 스케줄링 지연을 겪은 Pod 수.
  • Average Delay Time: 스케줄링되거나 삭제되기 전까지 Pending 상태로 보낸 평균 시간.
  • Resolved Count: 해소된(결국 스케줄링된) 지연 건수.
  • Unresolved Count: 아직 해소되지 않은 지연 건수. 이 숫자가 늘어난다는 것은 스케줄링 문제가 지금도 진행 중이라는 뜻입니다.

Average Pending Time by Hour. 선택한 범위 동안의 시간당 평균 pending 시간을 보여주는 영역 차트입니다. 배포 시간대나 피크 시간대처럼 지연이 몰리는 시점을 찾거나, 수정이 실제로 그래프를 움직였는지 확인하는 데 씁니다.

Delays 테이블. 지연된 Pod마다 한 행씩, 정렬과 필터링이 가능합니다: Pod Creation Time, Scheduling Delay, Workload Type, Namespace, Workload Name, Pod Name, Current Status(Resolved 또는 Pending), Latest Pod Condition, Volume Issues. Workload Type, Namespace, Workload Name, Status로 필터링해서 문제 하나만 골라낼 수 있습니다.

행을 펼쳐서 보는 상세 정보

행의 **+**를 클릭하면 해당 Pod의 전체 진단 내용이 펼쳐집니다.

Expanded scheduling-delay row showing conditions history, volume binding history, and timestamps
  1. Conditions history는 모든 스케줄러 조건을 시간순으로 나열하며, 각각 타임스탬프, 색상으로 구분된 배지(type, reason, status), 스케줄러가 남긴 메시지(예: 0/5 nodes are available: 2 Insufficient cpu, 3 node(s) had taint that the pod did not tolerate)를 함께 보여줍니다. 위에서 아래로 읽으면 지연이 어떻게 전개됐는지 알 수 있습니다.
  2. Volume binding history는 PersistentVolumeClaim을 사용하는 Pod에만 나타납니다. Pending 상태인 PVC마다 이름과 namespace, 바인딩 phase, 요청한 storage와 class, binding failure reason(예: 사용 가능한 볼륨 없음, 존 불일치)을 보여줍니다.
  3. Timestamps는 pod 생성 시각, 마지막 감지 시각, 지연이 해소된 시각을 요약합니다.

흔한 스케줄링 실패 원인

Latest Pod Condition 컬럼과 conditions history는 스케줄러가 남긴 원문 사유를 보여줍니다. 아래 항목과 대조해서 맞는 조치를 적용하세요.

Condition 메시지

  • PodExceedsFreeCPU / PodExceedsFreeMemory
  • "Insufficient CPU" 또는 "Insufficient memory"

근본 원인

  • 어떤 Node도 Pod의 리소스 request를 충족할 만큼 여유 CPU나 메모리가 없음
  • Pod 개수 제한 도달(node당 max pods)
  • 피크 시간대에 클러스터 용량이 가득 참

빠른 조치

긴급(즉시):

# Delete unused pods to free resources
kubectl delete pod <unused-pod> -n <namespace>
 
# Reduce resource requests temporarily
kubectl set resources deployment <name> -c=<container> --requests=cpu=500m,memory=512Mi

지속 가능(장기):

  • 클라우드 프로바이더를 통해 클러스터에 Node 추가
  • 자동 Node 프로비저닝을 위해 Cluster Autoscaler 활성화
  • Smart Sizing으로 리소스 request 최적화
  • 클러스터 전체의 과다 프로비저닝은 Sizing Console에서 확인

관련 문서

메모리 누수 감지워크로드 CPU 사용률