How to fix FailedScheduling: 0/N nodes are available in Kubernetes

KubernetesINTERMEDIATEHIGHUpdated Dec 6, 2025· 307 views

FailedScheduling means no node can accept your pod due to resource constraints, taints, affinity rules, or other scheduling requirements. Check the specific reason in pod events.

Quick fix

Fixes FailedScheduling: 0/N nodes are available

kubectl describe pod <pod-name>
  1. Check the specific scheduling failure reason
  2. Check node resources and allocations
  3. Check taints and tolerations
  4. Verify node selectors and affinity
kubernetes — error
kubectl describe pod <pod-name>
FailedScheduling: 0/N nodes are available

What this error means

FailedScheduling is a Kubernetes scheduler event indicating that a pod cannot be placed on any available node. The scheduler evaluates all nodes against the pod's requirements and constraints, and when none qualify, it generates this event. The event message includes the specific reason: "0/N nodes are available" followed by why each node was rejected. Common reasons include insufficient CPU/memory, taint/toleration mismatches, node affinity conflicts, or volume zone restrictions.

Typical symptoms

  • Pod remains in Pending state indefinitely
  • Events show FailedScheduling with specific constraint details
  • kubectl describe pod shows 0/N nodes are available message
  • Deployment cannot progress to desired replica count
  • New pods fail while existing pods continue running
  • Horizontal Pod Autoscaler cannot scale up

Common causes

  1. Insufficient CPU or memory resources on all nodes
  2. Node taints without matching pod tolerations
  3. Pod affinity or anti-affinity rules cannot be satisfied
  4. NodeSelector does not match any node labels
  5. PersistentVolume zone does not match any available nodes
  6. All nodes cordoned or marked unschedulable
  7. Node maximum pod limit reached
  8. PodDisruptionBudget blocking pod placement

How to fix "FailedScheduling: 0/N nodes are available"

1Check the specific scheduling failure reason

Get the detailed error message:

bash
kubectl describe pod <pod-name>

Look at the Events section for messages like:
- "0/3 nodes are available: 3 Insufficient cpu"
- "0/3 nodes are available: 3 node(s) had taints that the pod didn't tolerate"
- "0/3 nodes are available: 3 node(s) didn't match node selector"
- "0/3 nodes are available: 3 node(s) had volume node affinity conflict"

The message tells you exactly which constraint is blocking scheduling.

2Check node resources and allocations

Compare pod requirements against node capacity:

bash
# View node capacity and allocations
kubectl describe nodes | grep -A 10 "Allocated resources"

# Check actual resource usage
kubectl top nodes

# See what's consuming resources
kubectl top pods -A --sort-by=cpu
kubectl top pods -A --sort-by=memory

If nodes are overcommitted, reduce pod requests or add nodes.

3Check taints and tolerations

View node taints:

bash
kubectl describe nodes | grep Taints

If nodes are tainted, add matching tolerations:

yaml
spec:
  tolerations:
  - key: "dedicated"
    operator: "Equal"
    value: "app"
    effect: "NoSchedule"

Or remove the taint:

bash
kubectl taint nodes <node-name> dedicated:NoSchedule-
4Verify node selectors and affinity

Check if the pod requires specific nodes:

bash
kubectl get pod <pod-name> -o yaml | grep -A 10 nodeSelector
kubectl get pod <pod-name> -o yaml | grep -A 20 affinity

Verify nodes have the required labels:

bash
kubectl get nodes --show-labels

Add missing labels or adjust the pod's nodeSelector.

5Check for volume zone conflicts

PersistentVolumes in specific zones require pods in the same zone:

bash
# Check PV zone
kubectl get pv <pv-name> -o yaml | grep -A 5 nodeAffinity

# Check which zones have available nodes
kubectl get nodes -L topology.kubernetes.io/zone

Solutions:
- Add nodes to the volume's zone
- Create a new PV in a zone with available nodes
- Use a storage class with zone-spanning capability

6Uncordon nodes or add capacity

Check if nodes are schedulable:

bash
kubectl get nodes
# Look for SchedulingDisabled status

Uncordon cordoned nodes:

bash
kubectl uncordon <node-name>

Or scale up the cluster:

bash
# Cloud-specific scaling commands
# GKE
gcloud container clusters resize CLUSTER --num-nodes=5

# EKS (nodegroup)
eksctl scale nodegroup --cluster=CLUSTER --name=NODEGROUP --nodes=5

Advanced notes

FailedScheduling events are normal during cluster scaling or when cluster autoscaler is evaluating whether to add nodes. Brief pending periods are expected.

For complex scheduling requirements, use soft affinity (preferredDuringSchedulingIgnoredDuringExecution) instead of hard requirements when possible:

yaml
affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      preference:
        matchExpressions:
        - key: zone
          operator: In
          values:
          - us-east-1a

PodDisruptionBudgets can indirectly cause scheduling failures by preventing pods from being evicted to make room. Review PDBs if scheduling seems blocked without obvious resource constraints.

The scheduler caches node information for performance. In rare cases, stale cache causes scheduling decisions based on outdated node states. The cache refreshes automatically, but restarting the scheduler can force a refresh.

Frequently asked questions

What does "FailedScheduling: 0/N nodes are available" mean?
FailedScheduling is a Kubernetes scheduler event indicating that a pod cannot be placed on any available node. The scheduler evaluates all nodes against the pod's requirements and constraints, and when none qualify, it generates this event. The event message includes the specific reason: "0/N nodes are available" followed by why each node was rejected.
How do I fix "FailedScheduling: 0/N nodes are available"?
FailedScheduling means no node can accept your pod due to resource constraints, taints, affinity rules, or other scheduling requirements. Check the specific reason in pod events.
What causes "FailedScheduling: 0/N nodes are available"?
Insufficient CPU or memory resources on all nodes Node taints without matching pod tolerations Pod affinity or anti-affinity rules cannot be satisfied
Is the "FailedScheduling: 0/N nodes are available" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading