How do you pin a Pod to nodes with a given label?

WHAT THIS TESTS Whether you reach for the simplest correct mechanism rather than over-engineering scheduling constraints.

A GOOD ANSWER COVERS The simplest approach is nodeSelector. You first ensure the target nodes carry the label, for example kubectl label node node1 disktype=ssd, then add a nodeSelector map to the Pod's spec with disktype: ssd. The scheduler will only consider nodes whose labels match every key-value pair in the nodeSelector, so the Pod lands only on SSD nodes; if no matching node exists, the Pod stays Pending. This is a hard requirement and a single, declarative field. If you need richer logic, node affinity is the more powerful successor: it supports operators like In, NotIn, and Exists, distinguishes requiredDuringScheduling hard rules from preferredDuringScheduling soft preferences, and can express OR-style matching across multiple terms. But for a single exact label match, nodeSelector is the idiomatic, minimal answer. Note that nodeSelector attracts a Pod to labeled nodes; it does not repel other Pods, which is what taints and tolerations do.

COMMON WRONG ANSWERS Using taints and tolerations, which keep Pods off nodes rather than attracting them to a label. Hardcoding nodeName, which bypasses the scheduler and is brittle. Defaulting to complex node affinity for a trivial match. Forgetting to label the nodes first.

LIKELY FOLLOW-UPS When do you outgrow nodeSelector and need node affinity? How do taints and tolerations differ in intent? What happens if no node matches? How do you combine nodeSelector with tolerations?

ONE CONCRETE EXAMPLE After kubectl label nodes node1 disktype=ssd, a Pod spec with nodeSelector disktype: ssd schedules only onto node1 and any other node labeled disktype=ssd, staying Pending if none exist.