Taints and tolerations versus node affinity

WHAT THIS TESTS This checks whether you understand the directionality of the two mechanisms: taints are node-side repulsion, affinity is pod-side attraction. They solve different halves of placement.

A GOOD ANSWER COVERS A taint on a node repels all pods that do not carry a matching toleration. This is ideal for reserving dedicated nodes, for example GPU nodes or nodes funded by a specific team, so ordinary workloads never land there. A toleration only grants permission to schedule onto a tainted node; it does not attract the pod. Node affinity is the opposite: it pulls a pod toward nodes with matching labels but does nothing to keep other pods away. You use both together when you need exclusivity in both directions: taint the GPU nodes so general pods are repelled, give your GPU workload a matching toleration so it is allowed, AND add node affinity so the GPU workload is actively steered onto those nodes rather than landing on cheaper general nodes.

COMMON WRONG ANSWERS Saying a toleration guarantees the pod runs on the tainted node is the classic mistake; without affinity the tolerating pod may schedule elsewhere. Another error is using only a taint and expecting the special workload to find the node.

LIKELY FOLLOW-UPS The three taint effects NoSchedule, PreferNoSchedule, NoExecute. How node affinity differs from nodeSelector. What happens to running pods when NoExecute is added.

ONE CONCRETE EXAMPLE For a fleet of expensive A100 GPU nodes, taint them gpu=true:NoSchedule. Add that toleration plus nodeAffinity requiring accelerator=a100 to your training job. CPU services are repelled, and the GPU job is both permitted and pulled onto the right nodes.