A school-district node remains Ready but is cordoned. Why do new pods refuse to schedule there?
Select an answer to reveal the explanation.
Short Explanation
Cordon hangs a “no new guests” sign on a still-healthy house. The node can stay Ready—it just won’t take new pods.
Full Explanation
A school-district node that remains Ready but is cordoned refuses new Pods because cordon marks the node unschedulable (SchedulingDisabled) while Ready can still be true. Cordon hangs a “no new guests” sign on a still-healthy house—the node keeps heartbeating; the scheduler simply skips it for placement of new municipal workloads.
Cordon does not delete the node object. It does not always taint with NoExecute and kill every Pod immediately. It does not convert Ready to NotReady by blocking heartbeats—that would be kubelet failure, not cordon.
Exam caveat: kubectl drain cordons and evicts; cordon alone only blocks new scheduling. Existing Pods continue until drained or deleted. Uncordon restores schedulability after patch windows.
Operational check: kubectl cordon <node>, confirm SchedulingDisabled with Ready still true, attempt a new Deployment and see Pods avoid the node, then kubectl uncordon after maintenance and verify scheduling resumes. Keep civic change tickets precise: record object names, namespaces, and before/after observations so the next on-call engineer can replay the fix without guesswork. Prefer reversible steps and verify Ready or Bound state before closing the incident.