CKA Day 15 — Kubernetes Node Affinity Explained

Day 15 of the 40-day CKA Certification course by Tech Tutorials with Piyush. This lesson covers the advanced positive scheduling primitive that gives Pods fine-grained control over which nodes they run on — the expressive successor to nodeSelector.

Core Concepts

Node Affinity is a Pod-level scheduling constraint that attracts Pods to nodes with matching labels. It is the advanced, expressive successor to nodeSelector. While nodeSelector only supports exact equality matching (key = value), Node Affinity supports a rich set of operators (In, NotIn, Exists, DoesNotExist, Gt, Lt), multiple values, and soft/hard constraints.

The kube-scheduler evaluates Node Affinity during its filtering phase. If a Pod declares a required affinity and no node matches, the Pod remains Pending. If it declares a preferred affinity, the scheduler tries to honour it but will place the Pod elsewhere if no matching node is available.

Two Scheduling Types

Type	Full Name	Behaviour
Required	requiredDuringSchedulingIgnoredDuringExecution	Hard constraint — Pod is only scheduled on nodes that match the affinity rules. If no match, Pod stays Pending.
Preferred	preferredDuringSchedulingIgnoredDuringExecution	Soft preference — scheduler tries to match but will schedule on any available node if no match exists. Uses a weight field (1–100).

Key Insight: The suffix IgnoredDuringExecution is identical for both types. It means that once a Pod is scheduled, changes to node labels do not evict existing Pods. This is a critical distinction from NoExecute taints, which do evict. Source: CKA Day 15

YAML Patterns

Required (Hard Constraint)

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd
            - nvme

Preferred (Soft Preference with Weight)

spec:
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        preference:
          matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd

Operators

Operator	Behaviour	Example
In	Key has one of the listed values	disktype In [ssd, nvme]
NotIn	Key does not have any of the listed values	disktype NotIn [hdd]
Exists	Key exists (regardless of value)	gpu — matches any node with the gpu label
DoesNotExist	Key does not exist	!special — matches nodes without the special label
Gt	Key value > specified integer	memory Gt 64
Lt	Key value < specified integer	cpu Lt 8

Node Affinity vs Taints/Tolerations

Feature	Node Affinity	Taints + Tolerations
Direction	Pod chooses node (attract)	Node rejects Pod (repel)
Scope	Pod spec	Node property + Pod spec
Guarantee	Hard affinity guarantees placement on matching nodes	Taints only block; they don’t guarantee placement
Eviction	IgnoredDuringExecution — no eviction on label change	NoExecute evicts existing Pods
Multiple conditions	✅ Yes — rich operators and expressions	❌ Limited — key=value only

Practical Distinction: Taints prevent unwanted Pods from landing on a node, but they do not prevent a tolerated Pod from landing on a different node. Node Affinity actively pulls a Pod toward specific nodes. In production, the two are combined: taints keep general workloads off specialised nodes, and affinity ensures your workload lands on the right pool.

The Production Pattern: Taints + Affinity + Tolerations

The video synthesises the complete dedicated-node-pool pattern:

1. Label the node pool — kubectl label node -l gpu=true tier=ml
2. Taint the node pool — kubectl taint node -l gpu=true gpu=true:NoSchedule (repels everything else)
3. Add node affinity — Pod spec uses requiredDuringSchedulingIgnoredDuringExecution to require GPU nodes
4. Add toleration — Pod spec tolerates the gpu taint to allow landing on GPU nodes

This creates a “double-gated” node pool:

• Gate 1 (Taint): Only Pods with the toleration are allowed on GPU nodes
• Gate 2 (Affinity): Only Pods that need GPU nodes are attracted to them

CKA Exam Relevance

• Workloads & Scheduling (~15%): Expect tasks to add nodeAffinity so a Pod runs on nodes with specific labels, or to diagnose why a Pod is Pending due to unmatched affinity.
• Troubleshooting (~30%): A Pod stuck in Pending with 0/X nodes are available: X node(s) didn't match Pod's node affinity/selector is the classic required-affinity mismatch.
• Speed Pattern: Know the YAML nesting by heart: affinity → nodeAffinity → requiredDuringSchedulingIgnoredDuringExecution → nodeSelectorTerms → matchExpressions. The field names are long — practise writing them.

See Also

Wiki Concepts

• Kubernetes Node Affinity — deep-dive concept page with full YAML anatomy, operator reference, and exam commands
• Kubernetes Manual Scheduling — nodeName, nodeSelector, and nodeAffinity comparison table
• Kubernetes Taints and Tolerations — the negative scheduling counterpart
• Kubernetes Labels and Selectors — the metadata system that affinity builds on
• Kubernetes Architecture — kube-scheduler filtering phase
• Pod Fundamentals — the object that carries affinity rules

Related Sources

• CKA Day 14: Taints and Tolerations in Kubernetes — the inverse scheduling primitive covered in the previous video
• CKA Day 13: Static Pods, Manual Scheduling, Labels, and Selectors — covers nodeSelector basics

Creator / Entity

• Tech Tutorials with Piyush — 40-day CKA free course

---

Ingested on 2026-06-08. Part of the Consumed Videos library.