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

Process Flow - Pod affinity and anti-affinity

Pod Scheduling Request

↓

Check Pod Affinity Rules

↓

Match Affinity

↓

Check Pod Anti-Affinity Rules

↓

Reject Node

↓

Pod Scheduled on Node

When Kubernetes schedules a pod, it checks affinity and anti-affinity rules to decide which node is suitable. Affinity prefers nodes with matching pods; anti-affinity avoids nodes with certain pods.

Execution Sample

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - frontend
        topologyKey: kubernetes.io/hostname

This pod requests to be scheduled on a node that already runs pods with label app=frontend.

Process Table

Step	Pod Affinity Check	Pod Anti-Affinity Check	Node Decision	Reason
1	Check if node has pods with label app=frontend	Check if node has pods with conflicting labels	Pass affinity check	Node has pods with app=frontend label
2	N/A	No pods with conflicting labels found	Pass anti-affinity check	No anti-affinity conflict on node
3	N/A	N/A	Pod scheduled	Node meets affinity and anti-affinity rules
4	Check next node	Check anti-affinity	Fail affinity check	Node lacks pods with app=frontend label
5	N/A	N/A	Pod not scheduled on this node	Affinity rule not met

💡 Pod scheduled on first node that passes both affinity and anti-affinity checks

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
Node Affinity Match	false	true	true	true	true
Node Anti-Affinity Conflict	false	false	false	false	false
Pod Scheduled	false	false	false	true	true

Key Moments - 2 Insights

Why does the pod fail to schedule on a node without matching affinity labels?

Because the affinity rule requires the node to have pods with label app=frontend, nodes without this label fail the affinity check as shown in execution_table row 4.

What happens if a node has pods that violate anti-affinity rules?

The node is rejected during the anti-affinity check, preventing the pod from scheduling there, as indicated in execution_table row 2 if anti-affinity conflict was true.

Visual Quiz - 3 Questions

Look at the execution table, at which step does the pod get scheduled?

A Step 3

B Step 1

C Step 4

D Step 5

💡 Hint

Refer to the 'Node Decision' column where 'Pod scheduled' appears at Step 3.

According to the variable tracker, what is the value of 'Node Anti-Affinity Conflict' after Step 2?

A undefined

B true

C false

D null

💡 Hint

Check the 'Node Anti-Affinity Conflict' row under 'After Step 2' in variable_tracker.

If the pod affinity rule was removed, how would the scheduling change in the execution table?

A Pod would never schedule

B Pod would schedule on any node without affinity check

C Pod would fail anti-affinity check always

D Pod would schedule only on nodes with anti-affinity conflicts

💡 Hint

Without affinity rules, the affinity check step would be skipped, allowing scheduling on any node passing anti-affinity.

Concept Snapshot

Pod affinity and anti-affinity guide Kubernetes where to place pods.
Affinity prefers nodes with certain pods.
Anti-affinity avoids nodes with conflicting pods.
Rules use labels and topology keys.
Pods schedule only on nodes passing both checks.

Full Transcript

Pod affinity and anti-affinity are rules Kubernetes uses to decide where to place pods. When scheduling, Kubernetes checks if nodes have pods matching affinity labels to prefer those nodes. It also checks anti-affinity rules to avoid nodes with pods that should not be colocated. If a node passes both checks, the pod is scheduled there. This process ensures pods run close to or away from certain other pods based on labels and topology keys.