How do you stop new Pods scheduling on a node?

WHAT THIS TESTS Whether you understand the precise tool for blocking new scheduling without disrupting running workloads, and how it relates to draining.

A GOOD ANSWER COVERS The exact requirement, block new Pods but let current ones run, is what kubectl cordon does. Cordoning sets the node's spec.unschedulable field to true; the scheduler then refuses to place any new Pods on it, while every Pod already running stays untouched and keeps serving traffic. This is the first step of a maintenance workflow. When you are actually ready to take the node down, you run kubectl drain, which both cordons the node and gracefully evicts the existing Pods, honoring PodDisruptionBudgets and respecting graceful termination, so controllers reschedule those Pods elsewhere. After maintenance completes, kubectl uncordon flips the node back to schedulable so it rejoins the pool. The key distinction the interviewer is checking: cordon alone is non-disruptive and matches the stated goal, whereas drain is disruptive and goes further than asked.

COMMON WRONG ANSWERS Using kubectl drain when the question only asks to stop new scheduling, which would needlessly evict running Pods. Deleting the node, which is destructive. Manually adding a taint without realizing cordon is the purpose-built command. Forgetting to uncordon afterward.

LIKELY FOLLOW-UPS What does drain add on top of cordon? How do PodDisruptionBudgets affect a drain? How do you bring the node back? What flags does drain need for DaemonSets or local storage?

ONE CONCRETE EXAMPLE Before patching node1, you run kubectl cordon node1; new Pods now avoid it while the existing workloads keep running; later you kubectl drain node1 to evacuate it, perform maintenance, then kubectl uncordon node1 to return it to service.