Required vs preferred node affinity rules

WHAT THIS TESTS This probes your grasp of the two halves of an affinity rule name: the scheduling half (required versus preferred) and the execution half (IgnoredDuringExecution). Senior candidates separate placement guarantees from runtime guarantees.

A GOOD ANSWER COVERS requiredDuringSchedulingIgnoredDuringExecution is a hard rule. The scheduler treats matching node labels as a filter; if no node satisfies the nodeSelectorTerms the pod stays Pending indefinitely. preferredDuringSchedulingIgnoredDuringExecution is a soft rule with a weight from 1 to 100. The scheduler scores nodes by summing weights of satisfied preferences and prefers higher scores, but will still schedule onto a non-matching node rather than leave the pod unscheduled. The IgnoredDuringExecution suffix means these rules are evaluated only at scheduling time. Once a pod is bound and running, changing node labels so they no longer match does not evict the pod.

COMMON WRONG ANSWERS Saying a running pod gets kicked off when labels change confuses affinity with the not-yet-implemented RequiredDuringExecution semantics, which Kubernetes does not enforce. Another error is claiming preferred rules block scheduling under scarcity; they never do.

LIKELY FOLLOW-UPS How would you force re-evaluation on a running pod (answer: there is none for affinity; you delete and reschedule). How do weights combine across multiple preferred terms. How does this differ from taints with NoExecute, which DO evict running pods.

ONE CONCRETE EXAMPLE You require disktype equals ssd and prefer zone equals us-east-1a with weight 80. The pod will only land on SSD nodes, ideally in that zone. If you later relabel its node to disktype equals hdd, the running pod is untouched, but a restart could leave it Pending if no SSD node exists.