Node affinity and anti-affinity in Kubernetes - Step-by-Step Execution

Process Flow - Node affinity and anti-affinity

Pod Scheduling Request

↓

Check Node Affinity Rules

↓

Schedule Pod

↓

Conflicts with existing pods?

↓

Do NOT schedule

The scheduler checks node affinity rules first to find matching nodes. If none match, it checks anti-affinity rules to avoid conflicts before scheduling the pod.

Execution Sample

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd

This pod requests scheduling only on nodes labeled with disktype=ssd.

Process Table

Step	Action	Node Labels Checked	Affinity Match	Anti-Affinity Check	Scheduling Decision
1	Check node affinity on Node A	disktype=ssd, zone=us-east	Match	Skipped	Pod scheduled on Node A
2	Check node affinity on Node B	disktype=hdd, zone=us-west	No Match	Check anti-affinity	Anti-affinity no conflict, Pod scheduled on Node B
3	Check node affinity on Node C	disktype=hdd, zone=us-east	No Match	Check anti-affinity	Anti-affinity conflict, Pod not scheduled on Node C
4	No suitable nodes found	N/A	No	N/A	Pod remains pending

💡 Pod scheduled on first matching node or on node passing anti-affinity checks; otherwise remains pending.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
Pod Scheduled	False	True (Node A)	True (Node A, Node B)	True (Node A, Node B)	True (Node A, Node B)
Node Being Checked	None	Node A	Node B	Node C	N/A
Affinity Match	None	Yes	No	No	N/A
Anti-Affinity Conflict	None	N/A	No	Yes	N/A

Key Moments - 3 Insights

Why does the scheduler skip anti-affinity checks when node affinity matches?

Because node affinity is a strict requirement; if it matches, the pod can be scheduled immediately without checking anti-affinity (see execution_table step 1).

What happens if no nodes match the node affinity rules?

The scheduler then checks anti-affinity rules on nodes that don't match affinity to see if the pod can still be scheduled there (see execution_table steps 2 and 3).

Why might a pod remain pending even if some nodes match affinity?

If anti-affinity rules conflict on those nodes, the pod cannot be scheduled there and remains pending (see execution_table step 4).

Visual Quiz - 3 Questions

Look at the execution table, on which node does the pod get scheduled first?

A Node A

B Node B

C Node C

D Pod remains pending

💡 Hint

Check the Scheduling Decision column in step 1.

At which step does the scheduler find an anti-affinity conflict?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Look at the Anti-Affinity Conflict column in the variable tracker and Scheduling Decision in step 3.

If Node B had a disktype=ssd label, how would the scheduling decision change at step 2?

A Pod would not be scheduled on Node B due to anti-affinity conflict

B Pod would be scheduled on Node B due to affinity match

C Pod would remain pending

D Pod would be scheduled on Node C instead

💡 Hint

Refer to how affinity match leads to immediate scheduling in step 1.

Concept Snapshot

Node affinity lets pods request nodes with specific labels.
Anti-affinity prevents pods from scheduling near certain other pods.
Scheduler first checks node affinity; if no match, checks anti-affinity.
Pods schedule only on nodes passing these rules.
Affinity is a hard requirement; anti-affinity avoids conflicts.

Full Transcript

Node affinity and anti-affinity control where Kubernetes schedules pods. The scheduler first looks for nodes matching the pod's node affinity rules. If a node matches, the pod is scheduled there immediately. If no nodes match affinity, the scheduler checks anti-affinity rules to avoid placing pods near conflicting pods. If anti-affinity conflicts exist, the pod is not scheduled on those nodes and may remain pending. This process ensures pods run on suitable nodes and avoid conflicts with other pods.

Practice

1. What does nodeAffinity in Kubernetes primarily control?

easy

A. Which nodes a pod can be scheduled on based on node labels

B. The order in which pods start in a deployment

C. The network policies applied to pods

D. The resource limits of a pod

Solution

1. Step 1: Understand nodeAffinity purpose

   Node affinity is used to specify rules about which nodes a pod can run on, based on labels assigned to nodes.

2. Step 2: Compare options to nodeAffinity function

   Options B, C, and D relate to pod startup order, network policies, and resource limits, which are unrelated to node affinity.

3. Final Answer:

   Which nodes a pod can be scheduled on based on node labels -> Option A

4. Quick Check:

   nodeAffinity controls pod placement on nodes [OK]

Hint: Node affinity = pod placement by node labels [OK]

Common Mistakes:

• Confusing node affinity with pod resource limits
• Thinking node affinity controls pod startup order
• Mixing node affinity with network policies

2. Which of the following is the correct syntax to specify a required node affinity in a pod spec?

easy

A. "nodeAffinity": {"preferredDuringSchedulingIgnoredDuringExecution": [{"weight": 1, "preference": {"matchExpressions": [{"key": "disktype", "operator": "In", "values": ["ssd"]}]}}]}

B. "podAffinity": {"requiredDuringSchedulingIgnoredDuringExecution": {"labelSelector": {"matchLabels": {"disktype": "ssd"}}}}

C. "nodeSelector": {"disktype": "ssd"}

D. "nodeAffinity": {"requiredDuringSchedulingIgnoredDuringExecution": {"nodeSelectorTerms": [{"matchExpressions": [{"key": "disktype", "operator": "In", "values": ["ssd"]}]}]}}

Solution

1. Step 1: Identify required node affinity syntax

   Required node affinity uses the key requiredDuringSchedulingIgnoredDuringExecution with nodeSelectorTerms and matchExpressions to specify node labels.

2. Step 2: Check options for correct structure

   "nodeAffinity": {"requiredDuringSchedulingIgnoredDuringExecution": {"nodeSelectorTerms": [{"matchExpressions": [{"key": "disktype", "operator": "In", "values": ["ssd"]}]}]}} matches the required node affinity syntax. "nodeAffinity": {"preferredDuringSchedulingIgnoredDuringExecution": [{"weight": 1, "preference": {"matchExpressions": [{"key": "disktype", "operator": "In", "values": ["ssd"]}]}}]} is preferred affinity, C is nodeSelector (different syntax), and D is pod affinity, not node affinity.

3. Final Answer:

   "nodeAffinity": {"requiredDuringSchedulingIgnoredDuringExecution": {"nodeSelectorTerms": [{"matchExpressions": [{"key": "disktype", "operator": "In", "values": ["ssd"]}]}]}} -> Option D

4. Quick Check:

   Required node affinity uses requiredDuringSchedulingIgnoredDuringExecution [OK]

Hint: Required node affinity uses requiredDuringSchedulingIgnoredDuringExecution [OK]

Common Mistakes:

• Confusing preferred and required affinity syntax
• Using podAffinity instead of nodeAffinity
• Mixing nodeSelector with nodeAffinity syntax

3. Given this pod spec snippet, what will happen if a node has label zone: us-east-1a but no label disk: ssd?

{
  "affinity": {
    "nodeAffinity": {
      "requiredDuringSchedulingIgnoredDuringExecution": {
        "nodeSelectorTerms": [
          {
            "matchExpressions": [
              {"key": "zone", "operator": "In", "values": ["us-east-1a"]},
              {"key": "disk", "operator": "In", "values": ["ssd"]}
            ]
          }
        ]
      }
    }
  }
}

medium

A. The pod will be scheduled only if preferredDuringScheduling is set

B. The pod will not be scheduled on the node because it lacks the required disk label

C. The pod will be scheduled but with a warning

D. The pod will be scheduled because the zone label matches

Solution

1. Step 1: Analyze required node affinity conditions

   Required node affinity means all match expressions must be true for scheduling. The node must have both zone: us-east-1a and disk: ssd labels.

2. Step 2: Check node labels against requirements

   The node has zone: us-east-1a but lacks disk: ssd. This fails the required condition, so the pod cannot be scheduled there.

3. Final Answer:

   The pod will not be scheduled on the node because it lacks the required disk label -> Option B

4. Quick Check:

   Required affinity needs all labels matched [OK]

Hint: Required affinity means all labels must match [OK]

Common Mistakes:

• Assuming partial label match is enough
• Confusing required with preferred affinity
• Thinking pod schedules with warnings on missing labels

4. You wrote this pod spec with pod anti-affinity but pods are still scheduled on the same node. What is the likely error?

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        labelSelector:
          matchLabels:
            app: myapp
        topologyKey: "kubernetes.io/hostname"

medium

A. Incorrect labelSelector syntax causes failure

B. Missing nodeSelector in the pod spec

C. Using preferred instead of required anti-affinity allows scheduling on same node

D. topologyKey should be set to "zone" instead of hostname

Solution

1. Step 1: Understand pod anti-affinity types

   Preferred anti-affinity suggests avoiding co-location but does not enforce it strictly. Required anti-affinity enforces pods not to be scheduled together.

2. Step 2: Analyze the pod spec anti-affinity type

   The spec uses preferredDuringSchedulingIgnoredDuringExecution, which is a soft rule. This allows pods to be scheduled on the same node if needed.

3. Final Answer:

   Using preferred instead of required anti-affinity allows scheduling on same node -> Option C

4. Quick Check:

   Preferred anti-affinity is a soft rule [OK]

Hint: Preferred anti-affinity is soft; use required to enforce [OK]

Common Mistakes:

• Confusing preferred and required anti-affinity
• Assuming labelSelector syntax is wrong without checking
• Thinking topologyKey must be zone for anti-affinity

5. You want to ensure pods with label app=frontend never run on the same node as pods with label app=backend. Which affinity configuration achieves this?

hard

A. Use podAntiAffinity with requiredDuringSchedulingIgnoredDuringExecution and labelSelector matching app=backend

B. Use nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution and labelSelector matching app=backend

C. Use podAffinity with preferredDuringSchedulingIgnoredDuringExecution and labelSelector matching app=backend

D. Use nodeSelector with label app=backend

Solution

1. Step 1: Identify requirement to prevent co-location of pods

   Pod anti-affinity prevents pods from running on the same node as other pods matching certain labels.

2. Step 2: Choose required anti-affinity for strict enforcement

   Using requiredDuringSchedulingIgnoredDuringExecution enforces pods never co-locate on the same node.

3. Step 3: Match labelSelector to pods to avoid

   The labelSelector should match pods with app=backend to prevent frontend pods from scheduling on same node.

4. Final Answer:

   Use podAntiAffinity with requiredDuringSchedulingIgnoredDuringExecution and labelSelector matching app=backend -> Option A

5. Quick Check:

   Pod anti-affinity + required = strict pod separation [OK]

Hint: Use required podAntiAffinity to strictly separate pods [OK]

Common Mistakes:

• Using nodeAffinity instead of podAntiAffinity for pod separation
• Using preferred instead of required anti-affinity for strict rules
• Confusing podAffinity with podAntiAffinity