PacketSensei

AWS `0/N nodes are available: Insufficient cpu`: What It Means and How to Fix It

PacketSensei

0/N nodes are available: Insufficient cpu is the Kubernetes scheduler reporting that no node has room — measured against requests, not actual usage. It comes from EKS, and the message reads:

0/3 nodes are available: 3 Insufficient cpu, 3 Insufficient memory.

If you are here mid-incident, skip to how to tell which cause you have — the command there narrows it down faster than reading the list.

Quick reference
Error 0/N nodes are available: Insufficient cpu
Service EKS
Message 0/3 nodes are available: 3 Insufficient cpu, 3 Insufficient memory.
Most common cause Requests are set far above real usage

What it actually means

The scheduler places pods based on resource requests, not on what nodes are actually using. A cluster averaging 20% CPU can be completely unschedulable if every pod requests more than it needs.

The message enumerates every node and the reason each was rejected, which is more useful than it first appears — read the whole list, because different nodes are often rejected for different reasons.

Note also that allocatable capacity is less than the instance’s raw capacity. The kubelet reserves CPU and memory for system daemons, and on EKS that reservation scales with the node size.

Why it happens

Ranked by how often each one turns out to be the answer.

# Cause Fix
1 Requests are set far above real usage The dominant cause. A pod requesting 2 CPU and using 0.1 makes 95% of the node unusable. Right-size with Vertical Pod Autoscaler in recommendation mode, or read the actual usage from metrics.
2 The cluster genuinely needs more nodes Cluster Autoscaler or Karpenter should handle it. If it is not, check that the autoscaler is running, has permissions, and — for Cluster Autoscaler — that the node group has room below its maxSize.
3 Karpenter has no matching NodePool Karpenter provisions only what a NodePool allows. Requirements that exclude every available instance type produce an unschedulable pod and no new node.
4 A pod larger than any node A request for 8 CPU on a cluster of m5.large nodes (2 vCPU) can never schedule. The message says “Insufficient cpu” for every node, which is technically accurate and easy to misread as a capacity problem.
5 Taints, affinity, or topology spread constraints The message names these separately — “node(s) had untolerated taint”, “didn’t match pod topology spread constraints”. Read the specific reason rather than assuming CPU.
6 System reservations eating the difference A t3.medium has 2 vCPU but roughly 1.93 allocatable after kubelet reservations. A pod requesting exactly 2 will never fit.

How to tell which one you have

# The full scheduler reason, per node.
kubectl describe pod <pod> | sed -n '/Events:/,$p'

# Allocatable vs requested, per node.
kubectl describe nodes | grep -A8 'Allocated resources'

# Requests versus actual usage — the comparison that matters.
kubectl top nodes
kubectl top pods --all-namespaces --sort-by=cpu | head -20

# Is the autoscaler seeing the pending pod?
kubectl logs -n kube-system deploy/cluster-autoscaler --tail=50
kubectl logs -n karpenter deploy/karpenter --tail=50

Preventing it

Set requests from measured usage rather than from a template. Run Vertical Pod Autoscaler in recommendation mode across the cluster for a week and compare its numbers to what is configured — the gap is usually large and is exactly the capacity you are paying for and not using.

Use Karpenter rather than fixed node groups where the workload shape varies. It provisions an instance type that fits the pending pods instead of forcing pods into whatever shape you picked in advance.

Quota codes, limits and behaviour on this page were last checked against AWS documentation on 2026-08-22. AWS changes these; if something here does not match what you are seeing, trust the console and tell us.