What is Kubernetes Node Affinity?
Understand Kubernetes node affinity — required vs preferred rules, label matching, and how it differs from nodeSelector — for interviews.
Expected Interview Answer
Node affinity is a scheduling rule that constrains which nodes a Pod can be placed on, based on node labels, using expressive requiredDuringSchedulingIgnoredDuringExecution (hard) or preferredDuringSchedulingIgnoredDuringExecution (soft) matching rules that go beyond the older, simpler nodeSelector.
A Pod spec declares node affinity rules under spec.affinity.nodeAffinity, matching against node labels such as topology.kubernetes.io/zone or a custom disktype=ssd label, using operators like In, NotIn, Exists, and Gt/Lt for richer expressions than nodeSelector’s plain equality matching. Required rules act as hard constraints the scheduler must satisfy — the Pod stays Pending if no node matches — while preferred rules are soft, weighted hints the scheduler tries to honor but will ignore if no matching node is available, still placing the Pod elsewhere. The "IgnoredDuringExecution" suffix means these rules are only evaluated at scheduling time; if a node’s labels change after a Pod is already running there, Kubernetes does not evict or reschedule that Pod. Node affinity is commonly paired with inter-pod affinity/anti-affinity (which reasons about other Pods’ placement rather than node labels) to co-locate related workloads or spread replicas across failure domains.
- Targets specialized hardware like GPU or SSD nodes precisely
- Supports rich matching operators beyond simple label equality
- Offers both hard requirements and soft, weighted preferences
- Enables zone/region-aware placement for resilience and latency
AI Mentor Explanation
Node affinity is like a team management rule stating a fast bowler must only be selected for pitches labeled 'green and seaming' — a hard requirement, so if no such pitch is on the schedule, that bowler simply is not selected for the tour. A softer version is a preference for 'day matches’ over floodlit ones — selectors lean that way but will still pick the player for a night match if no day fixture exists. Crucially, if the pitch conditions change mid-match after the toss, the already-selected XI is not swapped out — the rule only applied at selection time. This distinction between a hard eligibility rule and a soft preference is exactly what required versus preferred node affinity captures.
Step-by-Step Explanation
Step 1
Label the nodes
Apply labels like disktype=ssd or topology.kubernetes.io/zone=us-east-1a to nodes.
Step 2
Declare affinity in the Pod spec
Use spec.affinity.nodeAffinity with required or preferred rules referencing those labels.
Step 3
Scheduler evaluates at placement time
Required rules must match or the Pod stays Pending; preferred rules influence scoring but are not mandatory.
Step 4
Rules are not re-evaluated later
IgnoredDuringExecution means a running Pod stays put even if the node's labels later change.
What Interviewer Expects
- Understanding of required vs preferred affinity and their scheduling impact
- Awareness that node affinity matches node labels, not other Pods
- Knowledge that affinity is evaluated only at scheduling time, not continuously
- Ability to contrast node affinity with nodeSelector and inter-pod affinity
Common Mistakes
- Confusing node affinity with inter-pod affinity/anti-affinity
- Assuming a running Pod gets evicted when node labels change
- Using only nodeSelector and not knowing when richer affinity is needed
- Forgetting that required rules can leave a Pod stuck Pending with no eligible node
Best Answer (HR Friendly)
“Node affinity lets us tell Kubernetes which kinds of nodes a workload is allowed or prefers to run on, based on labels like SSD storage or a specific availability zone. We can make it a strict requirement or just a preference, which gives us flexibility to target the right hardware while still letting the scheduler place the Pod somewhere reasonable if the ideal node is not available.”
Code Example
apiVersion: v1
kind: Pod
metadata:
name: gpu-training-job
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: hardware-type
operator: In
values: ["gpu"]
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 80
preference:
matchExpressions:
- key: topology.kubernetes.io/zone
operator: In
values: ["us-east-1a"]
containers:
- name: trainer
image: myorg/trainer:1.0Follow-up Questions
- What is the difference between node affinity and nodeSelector?
- How does inter-pod affinity differ from node affinity?
- What happens to a Pod if its required node affinity rule matches no node?
- How would you use node affinity for zone-aware high availability?
MCQ Practice
1. What does requiredDuringSchedulingIgnoredDuringExecution mean for a Pod?
The rule is a hard requirement at scheduling time; once the Pod is placed, later label changes on that node are ignored.
2. What happens if a Pod's required node affinity rule matches no available node?
A required rule is a hard constraint; if no node satisfies it, the Pod cannot be scheduled and stays Pending.
3. How does node affinity differ from nodeSelector?
Node affinity offers expressive match operators and both required and preferred rules, while nodeSelector only supports simple equality matching.
Flash Cards
What is node affinity? — A Pod scheduling rule that matches against node labels using required or preferred constraints.
Required vs preferred affinity? — Required is a hard constraint; preferred is a soft, weighted hint the scheduler tries to honor.
What does IgnoredDuringExecution mean? — The rule is only checked at scheduling time; running Pods are not evicted if node labels later change.
Node affinity vs nodeSelector? — Node affinity supports richer operators (In, NotIn, Exists) and soft preferences; nodeSelector only does exact match.