SchedulingDisabled: The node has been cordoned and will not receive new pods

SchedulingDisabled means someone marked the node unschedulable, usually before maintenance. Pods already running are untouched — cordon prevents new placement, it does not remove anything.

Applies to: All Kubernetes versions

What it means

Cordoning sets spec.unschedulable on the node and applies a taint, so the scheduler stops placing new pods there. It is deliberately non-disruptive: existing pods keep running. Draining is the separate step that evicts them. The two together are the standard maintenance sequence, and the gap between them is where a common mistake lives — a node cordoned during an incident and never uncordoned afterwards quietly reduces cluster capacity for weeks, because nothing about a cordoned node looks broken. It appears in kubectl get nodes as Ready,SchedulingDisabled, which is easy to read past.

Most common causes

• Deliberate cordoning before maintenance, an upgrade, or a replacement.
• A drain in progress, which cordons first.
• An automated node upgrade or repair process that cordoned the node.
• A cordon applied during an incident and never reversed.
• A cluster autoscaler preparing to remove the node.

How to diagnose it

1. List nodes and look at the status column: kubectl get nodes shows SchedulingDisabled explicitly.
2. Check the field directly: kubectl get node NODE -o jsonpath='{.spec.unschedulable}'.
3. Check whether pods are still running there: kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE.
4. Check whether an automated process cordoned it, by looking at node events and the autoscaler's logs.
5. Count how much of the cluster is cordoned — several forgotten cordons add up to a capacity problem that presents as unschedulable pods.

How to fix it

1. Uncordon when maintenance is complete: kubectl uncordon NODE.
2. If the node is being replaced, drain it and then delete it rather than leaving it cordoned indefinitely.
3. Check for forgotten cordons periodically. They are invisible in most dashboards and reduce capacity silently.
4. Investigate before uncordoning if an automated system cordoned the node — it may have had a reason.

Notes

Cordon and drain are different operations and it is worth being precise about which is wanted. Cordon alone leaves the workload running, which is right for a node you intend to keep. Drain moves the workload off, which is required before anything that will interrupt it.

Related

• FailedScheduling — The scheduler could not find a suitable node
• Cannot evict pod — A disruption budget is blocking the eviction

Sources

• Kubernetes documentation — Safely Drain a Node
• Kubernetes documentation — Nodes
• Kubernetes documentation — Taints and Tolerations