01
Check whether the Pod has a node at all
Pending covers more than one situation. A Pod that has not been scheduled differs from a scheduled Pod waiting for an image, volume, or container configuration. Inspect spec.nodeName and the PodScheduled condition before investigating application startup.
Our oversized test Pod had no assigned node. The scheduling condition reported Insufficient cpu. No application logs could explain this particular failure because its container never reached execution.
kubectl -n your-namespace get pod your-pod -o wide
kubectl -n your-namespace describe pod your-pod
kubectl -n your-namespace get pod your-pod -o yaml02
Read the effective request, not just a utilization graph
Inspect the resource declarations that reached the API, including init containers, defaults, and admission policy where applicable. CPU quantities use cores, and the m suffix denotes millicores: 1000 and 1000m are very different requests.
In our reproduction, cpu: "1000" requested one thousand cores. The scheduler rejected placement on the small lab node even though the container’s intended command was lightweight. The source of the problem was the declared reservation, not a measured CPU spike.
# Deliberately impossible lab request, not a recommended configuration:
resources:
requests:
cpu: "1000"03
Compare with eligible node capacity
Review node allocatable resources and existing allocations, along with placement rules. A node with free resources may still be ineligible because of taints, node selectors, or affinity. Read all reported scheduling reasons rather than selecting the first familiar phrase.
kubectl top can be useful operational context when a Metrics API is available, but it does not replace the scheduler’s request-based capacity accounting. A low live utilization reading alone does not prove that the requested Pod can fit.
kubectl get nodes
kubectl describe node your-node
kubectl -n your-namespace get limitrange,resourcequota04
Choose a justified resource or capacity change
If the request has a unit error, fix that declaration in the owning workload. If it correctly describes the application’s needs, provide suitable eligible capacity instead of shrinking it until scheduling succeeds. Consider rollout surge and other workloads when planning that change.
Our separate corrected lab Pod requested 10m CPU and 32Mi memory and became Ready. This comparison showed that the scheduler could place an appropriately sized test workload; it did not establish the minimum resources for an arbitrary application.
# Small lab workload only; measure your own application requirements.
resources:
requests:
cpu: 10m
memory: 32Mi05
Verify placement, startup, and useful behavior separately
Confirm that PodScheduled becomes true and spec.nodeName is populated. Then continue through image retrieval, container startup, readiness, and the operation you need the application to perform. Scheduling success is the beginning of that sequence.
Keep the original scheduling message and the corrected request or capacity change in the record. If the next Pod still remains Pending, compare its new scheduling reasons. Deleting the same unschedulable Pod repeatedly does not supply the missing capacity.
Sınırları bil
Tested on a disposable Kubernetes v1.32.2 node with a deliberately impossible 1000-core request. A separate small test Pod requesting 10m scheduled successfully. Those values establish the scheduling behavior; they are not production application sizing advice.
Kaynaklar ve ileri okuma
CoreTrailKit tarafından hazırlanan teknik yayın.
Bütün yazıları keşfet