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.