Required vs preferred node affinity rules
Understanding hard vs soft scheduling constraints.
required is a mandatory filter, preferred is a weighted preference, and IgnoredDuringExecution means rules apply only at scheduling time.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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.
A 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.
Interview question
A pod with required node affinity for disktype=ssd is running on an SSD node. An admin relabels that node to disktype=hdd. What happens to the running pod?
- a.It is rescheduled to another SSD node automatically
- b.It enters CrashLoopBackOff until a matching node appears
- c.It keeps running because affinity is ignored during executionCorrect
- d.It is immediately evicted because the node no longer matches
Why? this is the answer
IgnoredDuringExecution means affinity is only enforced at scheduling time, so a running pod is unaffected by later label changes. Eviction would only occur with NoExecute taints, not affinity.
Just read this? Test yourself on what you have been reading.
Read the original → kubernetes.io
- #kubernetes
- #scheduling
- #node-affinity
- #pods
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles