Pod가 CPU 부족으로 스케줄링되지 못했는지는 kubectl describe pod의 Events에서 FailedScheduling과 CPU 자원 부족 메시지를 확인하면 알 수 있습니다. 이어서 컨테이너별 Requests의 CPU 값을 대조해 요청량이 과도한지, 복제본 수 때문에 배치할 여유가 부족한지 판단합니다.
Pending 상태만으로는 CPU 부족을 단정할 수 없습니다
Pod를 배치할 노드가 없는 이유는 자원 부족일 수도 있고, 노드 선택 조건에 맞는 노드가 없기 때문일 수도 있습니다. 따라서 상태 이름보다 스케줄러가 남긴 실패 이유를 먼저 읽어야 합니다.
이 절차에는 대상 클러스터에 연결된 kubectl과 해당 네임스페이스의 Pod 및 이벤트를 조회할 권한이 필요합니다. 노드에 직접 로그인할 필요는 없습니다. 아래 명령의 payments와 api-demo는 실제 네임스페이스와 Pod 이름으로 바꿉니다.
describe에서 이벤트와 CPU 요청량을 순서대로 확인합니다
kubectl get pods -n payments로 Pending인 Pod의 정확한 이름을 확인합니다.kubectl describe pod api-demo -n payments로 상세 정보를 조회합니다.- Events에서 Reason이
FailedScheduling인 항목을 찾고, Message에 CPU 자원이 부족하다는 설명이 있는지 읽습니다. FailedScheduling이라는 이유만으로 CPU 부족이 확정되지는 않습니다. - Containers 아래 각 컨테이너의
Requests: cpu를 확인합니다.Limits만 보고 요청량을 판단하지 않습니다. - Node가 배정되어 있는지와 이벤트의 발생 시점도 확인합니다. 이전 실패 이후 이미 배치되었다면 과거 이벤트를 현재 상태와 구분해야 합니다.
설정 필드를 더 자세히 보려면 다음 명령으로 실제 Pod의 YAML을 조회할 수 있습니다.
kubectl get pod api-demo -n payments -o yaml출력의 spec.containers[].resources.requests.cpu를 확인합니다. 컨테이너가 여러 개라면 하나의 요청량만 확인하고 결론 내리지 말고 각 컨테이너의 설정을 살펴봅니다.
예시: CPU 1개를 요청하는 Pod가 들어갈 자리가 없는 경우
다음은 단일 컨테이너 Pod의 describe 출력에서 진단에 필요한 부분만 구성한 설명용 예시입니다. 실제 이벤트의 형식과 문구는 환경에 따라 다를 수 있습니다.
Status: Pending
Containers:
api:
Limits:
cpu: 1
Requests:
cpu: 1
Events:
Warning FailedScheduling default-scheduler
Node didn't have enough resource: CPU, requested: 1000, used: 1500, capacity: 2000Requests: cpu: 1은 CPU 1개, 즉 1000밀리코어를 요청한다는 뜻입니다. 예시 메시지의 CPU 수치는 밀리코어 단위라고 가정합니다. 스케줄러가 표시한 수치에서는 기존 사용분 1500에 새 요청 1000을 더하면 용량 2000을 넘으므로 해당 노드에 배치할 수 없습니다. 여기서 자원 계산 값을 CPU의 순간 실측 사용률로 해석하지 않아야 합니다.
이 예시가 보여주는 것은 해당 노드에서 CPU 요청을 수용할 수 없다는 점입니다. 전체 실패 원인을 판단하려면 다른 노드에 대한 설명도 읽어야 합니다. 어떤 노드는 CPU가 부족하고 다른 노드는 선택 조건을 만족하지 못할 수도 있습니다.
확인 결과에 따라 조정할 항목을 고릅니다
| 확인한 내용 | 검토할 항목 | 판단 시 주의점 |
|---|---|---|
| CPU 요청량이 의도보다 큼 | 워크로드 정의의 resources.requests.cpu | 배치만 성공시키려고 줄이지 말고 애플리케이션에 필요한 자원을 기준으로 검토합니다. |
| 개별 요청량은 타당하지만 복제본을 모두 배치할 여유가 없음 | Deployment의 replicas | 복제본을 줄이면 실행할 인스턴스 수도 줄어듭니다. 필요한 서비스 용량과 함께 판단합니다. |
| CPU 외의 배치 실패 이유도 표시됨 | 이벤트에 나온 노드 선택 조건 등 | CPU 요청량만 바꿔도 다른 실패 조건은 남을 수 있습니다. |
Deployment가 생성한 Pod라면 개별 Pod만 수정하려 하기보다 Deployment의 Pod 템플릿과 복제본 설정을 검토합니다. 조정 후에는 대상 Pod를 다시 조회해 노드 배정 여부와 새로운 이벤트를 확인합니다. 스케줄링에 성공하더라도 이후 컨테이너 시작까지 정상이라는 뜻은 아니므로 최종 상태도 확인해야 합니다.
describe에서 이벤트를 충분히 확인하기 어렵다면 같은 네임스페이스의 이벤트를 조회할 수 있습니다.
kubectl get events -n payments이 출력에는 다른 객체의 이벤트도 포함되므로 대상 Pod와 관련된 항목인지 확인합니다. CPU 부족 메시지를 찾지 못했다는 사실만으로 자원이 충분하다고 결론 내리지는 않습니다.
실무에서는 실패 메시지, 실제 CPU 요청량, 복제본 수를 함께 기록해 두면 조정 근거가 명확해집니다. 변경 뒤에는 과거 경고의 존재보다 새 Pod의 배치 상태와 후속 이벤트를 기준으로 해결 여부를 판단하세요.