iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
If a Pod is stuck in Pending with Insufficient cpu or Insufficient memory, the scheduler cannot find an eligible node with enough uncommitted allocatable capacity to satisfy the Pod’s resource requests. Check the Pod’s FailedScheduling event first, then compare its requests with node allocatable resources before choosing whether to right-size the request, free capacity, or add suitable nodes.
Confirm that insufficient resources are the reason the Pod is Pending
A Pod can be Pending for reasons other than CPU or memory. Begin with its scheduler events rather than changing resource settings on the assumption that capacity is the problem.
-
If you do not know the Pod’s namespace, list Pods across namespaces with
kubectl get pods -A. Note the target Pod’s name and namespace.Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy. -
Describe that Pod with
kubectl describe pod <pod-name> -n <namespace>. -
Read the Events section. Look for
FailedSchedulingand the full reason, such asInsufficient cpuorInsufficient memory. Repeated scheduling failures indicate the scheduler still cannot place the Pod.#1 Best Overall
If the event gives a different reason, investigate that reason instead. A container that has already been scheduled but fails to start is a different problem from a scheduler being unable to place a Pending Pod. See Kubernetes’ guide to debugging a running Pod and its general Pod debugging guide.
Understand why low current usage may not help
Kubernetes schedules Pods according to their resource requests, not simply a node’s moment-to-moment CPU or memory use. The scheduler checks whether a node has room for the request, accounting for requests already committed to Pods. A node may look quiet in usage graphs and still fail that check.
Requests and limits serve different purposes. Requests inform placement; limits are enforced for running containers by the kubelet and runtime. Changing a limit alone does not make an unsatisfied request fit. Kubernetes states, “The Pod remains in the PENDING state as long as the resource request cannot be satisfied.” See the official resource management documentation.
Compare the Pod’s requests with node Allocatable
Inspect node capacity and scheduled workload allocations with:
kubectl describe nodes
For each relevant node, distinguish Capacity—the node’s total resource amount—from Allocatable, the amount available for normal Pods after applicable system reservations. Check the resource allocation information and scheduled Pods in the node description as well as the Pod’s effective requests, including requests for every container.
Use Allocatable rather than Capacity as the basis for a fit check. Kubernetes explains that the scheduler does not over-subscribe Allocatable; node reservations mean total capacity is not all available to workload Pods. See the node resource reservation guide and node status reference.
Find out whether the problem is node size, cluster saturation, or eligibility
The request is too large for every node
Compare the Pod’s CPU and memory requests against the available allocatable resources on individual nodes. A request that exceeds what any one node can accommodate will not fit, even if the cluster has enough free resources in aggregate across smaller nodes. The remedy is a node with enough allocatable capacity or a justified adjustment to the request.
Recommended Free Tools
Eligible nodes are already committed
If nodes are large enough but their allocatable resources are committed to other Pods’ requests, the cluster may be saturated for this workload. Inspect the scheduled Pods and their allocations in kubectl describe nodes. Do not treat low instantaneous use as proof that those requests can safely be reclaimed.
Best Value
Nodes with capacity are not eligible
A node with sufficient resources still cannot receive the Pod if it is excluded from the eligible set. Check node taints and whether the Pod has matching tolerations. Kubernetes’ Pod scheduling troubleshooting guidance covers resource insufficiency and node eligibility considerations.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Choose the fix that matches the cause
Use the least disruptive option that reflects the workload’s real needs. Kubernetes lists adjusting requests, removing unneeded workloads, and adding nodes among the possible responses to insufficient resources; the right choice depends on whether the request is wrong, existing workloads are expendable, or the cluster needs more capacity. See Kubernetes’ scheduling troubleshooting guidance.
| Option | When it fits | Trade-off |
|---|---|---|
| Correct an inflated request | The configured request is higher than the workload’s validated needs. | Can allow scheduling without adding capacity, but lowering a request changes the scheduler’s reservation assumption. Validate the workload rather than reducing it just to clear the event. |
| Remove unneeded Pods or scale down replicas | Some workloads or replicas are no longer needed and their committed requests can be released. | May free capacity sooner than adding nodes, but scaling down removes replicas and can affect service availability or redundancy. |
| Add appropriate nodes | Existing nodes cannot fit the request or the cluster needs durable additional capacity. | Supplies capacity for workloads that need it, but entails infrastructure and operational cost; new nodes must also be eligible for the Pod. |
| Resolve node eligibility constraints | Nodes have resources but taints prevent placement and the Pod is not appropriately tolerated. | Can make existing capacity usable, but change taints or tolerations only when that matches the intended placement policy. |
A memory-backed emptyDir can consume memory, and memory use above a request is not counted as additional scheduler reservation. That affects runtime capacity and safety, but it does not itself resolve a FailedScheduling event; size requests for actual workload needs and account for runtime behavior separately. Details are in the Kubernetes resource management documentation.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Verify that the Pod can now be scheduled
After making a change, inspect the Pod again with kubectl describe pod <pod-name> -n <namespace>. Check whether new events still report FailedScheduling for insufficient CPU or memory. If they do, compare the request against the updated allocatable resources and eligible nodes; if the event changed, follow the new reason rather than repeating the same resource adjustment.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
