Pod가 Pending에서 안 움직일 때 — 스케줄링 실패 원인과 진단
Kubernetes 공식 문서(kubernetes.io) 및 운영 블로그 종합 — 아키텍처부터 스케줄링까지 (웹 리서치, 2026) — Kubernetes 공식 문서(concepts/overview/components, workloads/pods, services-networking, pod-qos, pod-lifecycle) + 운영 블로그(Komodor, Datadog 등) 교차 확인 웹 리서치 종합(Komodor, Datadog, Kubernetes 공식문서 taint-and-toleration)
이 모듈을 다 읽으면
- Pod가 Pending에 머무는 대표적 원인들(자원 부족, 노드 선택 제약, 미바인딩 PVC 등)을 나열할 수 있다
- kubectl describe pod의 Events 섹션이 왜 가장 먼저 봐야 할 진단 지점인지 설명할 수 있다
k8s-learn-01의 스케줄러 동작과 k8s-learn-05의 requests를 전제로, 스케줄러가 '이 Pod를 어디에도 배정 못 하는' 대표적 상황들과 실무 진단 순서를 정리한다.
왜 Pending에 머무는가 — 대표 원인들
가장 흔한 원인은 자원 부족이다 — Pod가 선언한 requests(k8s-learn-05)만큼의 여유 CPU·메모리를 가진 노드가 하나도 없으면 스케줄러는 배정을 못 하고 계속 재시도만 한다. 그 외에도 nodeSelector·nodeAffinity로 특정 조건의 노드만 지정했는데 그런 노드가 실제로 없는 경우, taint(노드가 스스로에게 붙인 '이런 Pod는 오지 마' 표식)와 Pod의 toleration(그 taint를 감수하겠다는 허용)이 안 맞는 경우, 그리고 PersistentVolumeClaim이 아직 바인딩될 PersistentVolume을 못 찾은 경우가 있다.
핵심 포인트
- 자원 부족: requests만큼의 여유 CPU·메모리를 가진 노드가 없음(가장 흔함)
- nodeSelector/nodeAffinity 조건에 맞는 노드 부재, taint-toleration 불일치, PVC가 바인딩할 PV를 못 찾음
진단은 kubectl describe pod의 Events부터
위 원인들을 하나씩 추측하기보다, `kubectl describe pod <이름>`의 Events 섹션을 먼저 보는 것이 가장 빠른 진단 경로다 — 스케줄러가 배정을 시도했다가 실패한 이유(예: '0/5 nodes are available: 3 Insufficient cpu, 2 node(s) had taint...')를 사람이 읽을 수 있는 메시지로 그대로 남기기 때문이다. 이 메시지 하나로 자원 부족인지, 노드 선택 제약인지, taint 문제인지를 대부분 바로 좁힐 수 있어, 원인을 순차적으로 하나씩 배제해나가는 것보다 훨씬 빠르다.
핵심 포인트
- `kubectl describe pod`의 Events 섹션에 스케줄러 실패 사유가 사람이 읽을 수 있는 메시지로 그대로 남음
- 원인을 하나씩 추측·배제하기 전에 이 메시지를 먼저 확인하는 것이 가장 빠른 진단 경로