How to fix node(s) were unschedulable in Kubernetes

KubernetesBEGINNERMEDIUMUpdated Dec 5, 2025· 231 views

This scheduling error occurs when all available nodes are marked as unschedulable, typically because they have been cordoned for maintenance or have NoSchedule taints.

Quick fix

Fixes node(s) were unschedulable

kubectl get nodes
  1. Check node status and taints
  2. Uncordon nodes if maintenance is complete
  3. Remove NoSchedule taints if appropriate
  4. Add tolerations to your pod if needed
kubernetes — error
kubectl get nodes
node(s) were unschedulable

What this error means

The "node(s) were unschedulable" error indicates that the Kubernetes scheduler cannot place your pod on any available node because those nodes are marked as unschedulable. This happens when nodes have been cordoned (manually marked unschedulable) or have the node.kubernetes.io/unschedulable:NoSchedule taint. When a node is cordoned, it shows a SchedulingDisabled status. Existing pods continue running, but no new pods can be scheduled there. This is commonly used during planned maintenance, node upgrades, or when draining nodes. The error often appears alongside other scheduling failures (insufficient resources, taints not tolerated), so you may need to address multiple issues to successfully schedule your pod.

Typical symptoms

  • Pod stuck in Pending state
  • kubectl describe pod shows "node(s) were unschedulable"
  • kubectl get nodes shows SchedulingDisabled status
  • New deployments fail to schedule any pods
  • Cluster autoscaler not provisioning new nodes

Common causes

  1. Nodes manually cordoned with kubectl cordon
  2. Nodes being drained for maintenance or upgrades
  3. Cluster autoscaler cordoned nodes for scale-down
  4. All nodes have NoSchedule taints without matching pod tolerations
  5. Control plane nodes tainted and no worker nodes available

How to fix "node(s) were unschedulable"

1Check node status and taints

List all nodes and their scheduling status:

bash
kubectl get nodes

Look for nodes with SchedulingDisabled. Then check taints:

bash
kubectl describe node <node-name> | grep -A5 Taints
2Uncordon nodes if maintenance is complete

If nodes were cordoned for maintenance that's now finished, uncordon them:

bash
# Uncordon a specific node
kubectl uncordon <node-name>

# Uncordon all nodes
kubectl get nodes -o name | xargs -I{} kubectl uncordon {}
3Remove NoSchedule taints if appropriate

Remove taints that are blocking scheduling:

bash
# Remove a specific taint
kubectl taint node <node-name> node.kubernetes.io/unschedulable:NoSchedule-

# For control plane nodes (if you want to schedule pods there)
kubectl taint node <node-name> node-role.kubernetes.io/control-plane:NoSchedule-

Note the minus sign (-) at the end removes the taint.

4Add tolerations to your pod if needed

If the taints are intentional, add tolerations to your pod spec:

yaml
spec:
  tolerations:
  - key: "node.kubernetes.io/unschedulable"
    operator: "Exists"
    effect: "NoSchedule"

This allows the pod to be scheduled on cordoned nodes.

5Scale up worker nodes

If all nodes are legitimately unavailable, add more nodes:

bash
# For managed Kubernetes (GKE example)
gcloud container clusters resize <cluster> --num-nodes=3

# For EKS with managed node groups
aws eks update-nodegroup-config --cluster-name <cluster> \
  --nodegroup-name <nodegroup> --scaling-config minSize=3,maxSize=5,desiredSize=3

Advanced notes

The SchedulingDisabled status is distinct from node readiness. A cordoned node can be Ready but unschedulable—it's healthy and running pods, just not accepting new ones.

When using kubectl drain, nodes are automatically cordoned first. After drain completes and you've performed maintenance, remember to uncordon:

bash
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data
# Perform maintenance
kubectl uncordon <node>

Different Kubernetes versions use different taint keys for control plane nodes:
- Pre-1.24: node-role.kubernetes.io/master:NoSchedule
- 1.24+: node-role.kubernetes.io/control-plane:NoSchedule

Check your cluster version when managing control plane taints.

Frequently asked questions

What does "node(s) were unschedulable" mean?
The "node(s) were unschedulable" error indicates that the Kubernetes scheduler cannot place your pod on any available node because those nodes are marked as unschedulable. io/unschedulable:NoSchedule taint. When a node is cordoned, it shows a SchedulingDisabled status.
How do I fix "node(s) were unschedulable"?
This scheduling error occurs when all available nodes are marked as unschedulable, typically because they have been cordoned for maintenance or have NoSchedule taints.
What causes "node(s) were unschedulable"?
Nodes manually cordoned with kubectl cordon Nodes being drained for maintenance or upgrades Cluster autoscaler cordoned nodes for scale-down
Is the "node(s) were unschedulable" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading