Skip to content
Latchkey

Kubernetes "FailedScheduling: Insufficient cpu/memory" in CI

The pod stays Pending because the scheduler found no node with enough allocatable CPU or memory to meet its resource requests. The cluster is at capacity for what the pod asks for -- it is a sizing problem, not a manifest syntax error.

What this error means

A kubectl describe pod shows FailedScheduling with 0/N nodes are available: N Insufficient cpu (or memory). The deploy/rollout in CI hangs waiting for the pod to become Ready. It can be transient if autoscaling is mid-scale, or persistent if requests exceed any node.

kubectl describe
Warning  FailedScheduling  default-scheduler
  0/3 nodes are available: 3 Insufficient cpu. preemption: 0/3 nodes are
  available: 3 No preemption victims found for incoming pod.

Common causes

Requests exceed available node capacity

The pod's resources.requests are larger than the free allocatable CPU/memory on every node, so no node can host it.

Cluster at capacity / autoscaler lagging

Existing workloads consume the nodes and the cluster autoscaler has not yet added capacity, so scheduling waits (a transient state) until a node is added.

How to fix it

Right-size the requests or add capacity

  1. Compare the pod's requests against node allocatable: kubectl describe nodes | grep -A5 Allocatable.
  2. Lower over-large requests to what the workload actually needs, or add/scale nodes.
  3. If autoscaling, confirm the cluster autoscaler can provision a node big enough.
Terminal
kubectl describe nodes | grep -A6 "Allocated resources"
kubectl get pod <pod> -o jsonpath='{.spec.containers[*].resources}'

Wait for or trigger scale-up

  1. If the autoscaler is mid-scale, the pod schedules once a node joins -- this clears on its own.
  2. Ensure node group max size is high enough to add the needed node.
  3. Remove conflicting affinity/taints that may be excluding otherwise-fitting nodes.

How to prevent it

  • Set realistic resource requests based on observed usage, not guesses.
  • Configure cluster autoscaling headroom for bursty deploys.
  • On Latchkey, self-healing managed runners auto-retry transient deploy steps so a pod that is Pending only while the cluster autoscaler adds a node does not fail the pipeline.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →