Kubernetes Pod Pending 해결: 자원 부족·taint·PVC·스케줄링 점검

AI로 제작한 개념 일러스트입니다. Pod Pending은 이벤트를 기준으로 자원·스케줄링 정책·스토리지를 나누어 확인합니다.

 

Kubernetes Pod가 Pending에 머무르면 이미지를 다시 빌드하기 전에 스케줄러가 노드를 배정했는지부터 보세요. Pending은 노드 배정을 기다릴 때뿐 아니라 컨테이너 설정이나 이미지 다운로드를 기다리는 단계에도 나타날 수 있습니다. FailedScheduling 이벤트와 Pod의 Node 값이 원인 분기의 출발점입니다.

1. 먼저 이벤트와 Node 배정 여부를 확인하세요

아래 예시는 읽기 전용 조회입니다. app은 실제 네임스페이스로, my-pod는 실제 Pod 이름으로 바꾸세요.

kubectl get pod my-pod -n app -o wide
kubectl describe pod my-pod -n app
kubectl get events -n app --sort-by=.lastTimestamp
kubectl get nodes
kubectl get pvc -n app

Pod에 노드가 없다면 describe 아래쪽 이벤트의 FailedScheduling 사유를 우선 읽습니다. 노드가 배정됐다면 이미지 다운로드, 볼륨 연결, 컨테이너 생성 단계도 확인해야 합니다. 이미지 다운로드 실패는 별도 원인이므로 기존 ImagePullBackOff 해결 글을 이어서 보세요.

2. 흔한 원인을 이벤트 문구별로 나누기

관찰한 이벤트/상태	점검할 대상	성급히 하지 말 일
Insufficient cpu 또는 memory	Pod requests, 노드 할당 가능 자원	근거 없이 requests를 0으로 낮추기
untolerated taint	노드 taint와 Pod toleration	전체 노드에서 taint 제거하기
node affinity/selector 불일치	노드 label과 배치 조건	보안·격리 라벨을 무조건 삭제하기
PVC Pending 또는 볼륨 충돌	PVC, StorageClass, 볼륨 토폴로지	데이터가 있는 PVC를 지우기
Node 지정됨, 이미지 대기	이미지 이름·인증·네트워크	스케줄러만 재시작하기

3. 자원 부족은 사용률이 아니라 요청량으로도 발생합니다

Kubernetes 스케줄러 문서는 후보 노드를 먼저 필터링한 뒤 점수를 매긴다고 설명합니다. CPU가 현재 한가해 보여도 이미 배정된 Pod의 요청량을 합치면 새 Pod의 요청을 수용하지 못할 수 있습니다. kubectl describe node NODE_NAME의 할당 자원 표와 Pod의 resources.requests를 함께 보세요.

가상 예시로 노드의 할당 가능한 CPU가 2코어이고 기존 Pod 요청량 합계가 1.8코어라면 0.5코어를 요청하는 새 Pod는 그 노드에 배치될 수 없습니다. 이 숫자는 실제 클러스터 측정값이 아닙니다. 무턱대고 요청량을 낮추면 실행 뒤 성능과 안정성이 나빠질 수 있으므로 부하 측정과 노드 증설 가능성을 함께 검토합니다.

4. taint·선호 노드·스토리지를 별도로 보세요

노드에 특수 작업만 올리도록 taint를 둔 경우 Pod에 맞는 toleration이 없으면 배치가 막힐 수 있습니다. 반대로 toleration만 추가해도 node selector나 affinity가 일치하지 않으면 해결되지 않습니다. 노드의 격리 목적을 확인한 뒤 Pod 배치 정책을 수정해야 합니다.

스토리지 사용 Pod는 Kubernetes StorageClass 문서의 볼륨 바인딩 방식도 확인하세요. WaitForFirstConsumer처럼 Pod 배치와 볼륨 생성을 함께 결정하는 방식이 있습니다. PVC가 Pending이라고 무조건 스토리지가 고장 난 것은 아닙니다. PVC 이벤트와 StorageClass, 사용 가능한 노드 영역을 같이 읽으세요.

5. 자주 묻는 질문

Pod를 삭제하고 다시 만들면 해결되나요? 자원·taint·스토리지 조건이 같다면 새 Pod도 같은 이유로 대기할 가능성이 큽니다. 이벤트를 먼저 보세요.

노드가 Ready면 왜 배정되지 않나요? Ready는 스케줄러의 모든 필터를 통과했다는 뜻이 아닙니다. 요청 자원과 배치 정책을 확인해야 합니다.

Pending과 CrashLoopBackOff는 같은 문제인가요? 아닙니다. 후자는 컨테이너가 시작된 뒤 반복 종료되는 현상입니다. 먼저 노드 배정과 이벤트 단계부터 구분하세요.

6. 수정 뒤 확인할 상태

배치 조건을 수정했다면 kubectl get pod -n app -o wide에서 노드가 지정됐는지 보고, kubectl describe pod의 새로운 이벤트를 확인합니다. 이후 Running과 Ready는 별도 지표로 확인하세요. 배치 성공만으로 애플리케이션의 정상 응답이 보장되지는 않습니다.

자료 확인: 2026년 9월 29일. 노출 가능성은 실측 검색량이 아니라 구체적인 Pending·FailedScheduling 장애 해결 의도에 따른 추정입니다.