Node affinity is the expressive successor to nodeSelector. While nodeSelector uses simple key=value label matching, node affinity supports operators (In, NotIn, Exists, DoesNotExist, Gt, Lt), soft preferences with weights, and the distinction between hard requirements and soft preferences.

1. nodeSelector vs Node Affinity

# nodeSelector — simple, limited:
spec:
  nodeSelector:
    disktype: ssd
    zone: us-east-1a
# Pod MUST go to a node with BOTH labels. No "or", no "prefer", no operators.

# Node affinity — powerful, expressive:
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution: ...   # Hard
      preferredDuringSchedulingIgnoredDuringExecution: ...  # Soft

2. Required Node Affinity (Hard)

requiredDuringSchedulingIgnoredDuringExecution — the Pod must schedule on a matching node, or stays Pending.

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:                # OR between terms
          - matchExpressions:             # AND between expressions in same term
              - key: topology.kubernetes.io/zone
                operator: In
                values:
                  - us-east-1a
                  - us-east-1b
              - key: node.kubernetes.io/instance-type
                operator: In
                values:
                  - m5.xlarge
                  - m5.2xlarge

Logic Rules

• Multiple nodeSelectorTerms → OR (match any one term)
• Multiple matchExpressions within one term → AND (all must match)

# This means: Node must be in (us-east-1a OR us-east-1b) AND (m5.xlarge OR m5.2xlarge)
# If you want "zone a with m5" OR "zone c with c5", use two separate nodeSelectorTerms

Available Operators

3. Preferred Node Affinity (Soft)

preferredDuringSchedulingIgnoredDuringExecution — the scheduler tries to match, but schedules elsewhere if no matching node is available. Uses weights to express preference strength.

spec:
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 80                     # 1-100: higher = stronger preference
          preference:
            matchExpressions:
              - key: topology.kubernetes.io/zone
                operator: In
                values: ["us-east-1a"]    # Strongly prefer zone a
        - weight: 20
          preference:
            matchExpressions:
              - key: node.kubernetes.io/instance-type
                operator: In
                values: ["m5.xlarge"]     # Weakly prefer m5.xlarge

How Weights Work

# The scheduler scores each node:
# For each preference that matches → add its weight to the node's score
#
# Node A: zone=us-east-1a, type=m5.xlarge → score += 80 + 20 = 100
# Node B: zone=us-east-1a, type=c5.xlarge → score += 80 + 0  = 80
# Node C: zone=us-east-1b, type=m5.xlarge → score += 0  + 20 = 20
# Node D: zone=us-east-1b, type=c5.xlarge → score += 0  + 0  = 0
#
# Scheduler picks Node A (highest score)
# But if Node A is full, it can still use B, C, or D (soft, not hard)

Combining Required + Preferred

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:     # MUST
        nodeSelectorTerms:
          - matchExpressions:
              - key: topology.kubernetes.io/zone
                operator: In
                values: [us-east-1a, us-east-1b, us-east-1c]  # Must be in these zones
      preferredDuringSchedulingIgnoredDuringExecution:    # PREFER
        - weight: 70
          preference:
            matchExpressions:
              - key: topology.kubernetes.io/zone
                operator: In
                values: [us-east-1a]     # Prefer zone a among the allowed zones
# Result: Must be in zone a/b/c. Strongly prefers a. Falls back to b/c if a is full.

4. "IgnoredDuringExecution" — What It Means

The full name requiredDuringSchedulingIgnoredDuringExecution means:

• During scheduling: The rule is enforced (required or preferred)
• During execution: If node labels change after scheduling, the Pod stays — it's NOT evicted

# Example: Pod requires zone=us-east-1a
# Pod schedules on node in us-east-1a ✓
# Admin removes the zone label from the node
# Pod STAYS — the rule is only checked at scheduling time

A future K8s feature (requiredDuringSchedulingRequiredDuringExecution) would evict Pods when labels change — but it doesn't exist yet.

5. Common Node Labels for Affinity

# See all labels on a node:
kubectl get node worker-1 --show-labels

# Add a custom label:
kubectl label node worker-3 gpu=nvidia-a100

6. nodeSelector vs Affinity — When to Use Which

Summary

requiredDuringSchedulingIgnoredDuringExecution:
  nodeSelectorTerms:
    - matchExpressions:
        - key: node.kubernetes.io/lifecycle
          operator: NotIn
          values: ["spot"]