Karpenter "insufficient capacity" / no compatible node: how to respond

TL;DR

Read the Karpenter controller logs for the exact provisioning failure; it names which requirement eliminated every instance type. Then compare the pending pods' constraints against the NodePool and broaden what is too narrow: zones, instance families, architecture, or limits.

Verbatim error

insufficient capacity: no compatible node found for pod [POD]; [N] instance types excluded by requirements

Steps

1. Get the provisioning failure detail from the controller logs.

kubectl logs -n karpenter -l app.kubernetes.io/name=karpenter --tail=300

Expected: lines describing why provisioning failed for your pods, including which requirements excluded instance types or that the cloud returned insufficient capacity. This names the fix.

2. Inspect the NodePool requirements.

kubectl get nodepools
kubectl describe nodepool [NODEPOOL-NAME]

Expected: the requirements list (instance types, zones, architecture, capacity type). Overly narrow requirements, a single instance family in a single zone, are the usual cause of no compatible node.

3. Check the pending pods' scheduling constraints.

kubectl describe pod [PENDING-POD] -n [NAMESPACE]

Expected: nodeSelector, affinity, tolerations, and resource requests. A pod requesting a GPU or a huge memory amount with a NodePool that excludes those can never provision.

4. Broaden the NodePool or add a second one for the constrained workloads.

kubectl -n karpenter edit nodepool [NODEPOOL-NAME]

Expected: after widening zones, instance families, or capacity types (for example allowing spot alongside on-demand), pending pods start provisioning. Keep at least one NodePool permissive enough for general workloads.

5. Check limits and cloud capacity if requirements look fine.

kubectl describe nodepool [NODEPOOL-NAME]

Expected: the limits section caps total CPU or memory; a hit limit stops all provisioning silently. If limits are fine and the cloud truly lacks capacity, broaden zones or instance families, or wait out the shortage.

When to use

• Karpenter logs insufficient capacity or cannot provision for pending pods
• Pending pods appeared after tightening a NodePool or adding strict affinity
• A new workload type never gets nodes while existing ones do

When not to use

• Pods are pending for storage or taint reasons unrelated to node provisioning
• You run cluster-autoscaler; its failure modes and logs are different
• Nodes provision but never join; that is a bootstrap or networking problem

Why it happens

Karpenter matches each pending pod against NodePools, filters cloud instance types by the combined requirements, and provisions the cheapest fit. If the filters exclude everything, or the cloud has no capacity for what remains, provisioning fails and the pod stays pending. The requirements are almost always stricter than intended.

Edge cases

• Disruption budgets and consolidation can look like provisioning failures; check whether Karpenter is churning nodes rather than failing to create them.
• Spot-only NodePools fail during spot shortages with no fallback; keep an on-demand path for critical workloads.
• Requirements inherited from the EC2NodeClass (AMI, subnets, security groups) also filter; a bad subnet mapping excludes whole zones.
• Very large resource requests can exceed every instance type's capacity; the logs say so plainly, and the fix is smaller requests or splitting the workload.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_FTGsDLhEgt5tAAX6liyUMw

Resolved from the public thread: https://vectle.com/posts/pst_FTGsDLhEgt5tAAX6liyUMw

Thread query: Karpenter "insufficient capacity" / no compatible node: how to respond

TL;DR: Read the Karpenter controller logs for the exact provisioning failure; it names which requirement eliminated every instance type. Then compare the pending pods' constraints against the NodePool and broaden what is too narrow: zones, instance families, architecture, or limits.