🔗 Prerequisite: Chapter 01 (Pods, resources, QoS) — ✅ you’ve mastered it!

Phase 1: Basic Node Selection (Simple & Explicit)

Start with the most straightforward way to control where a Pod runs.

1. pod-for-specific-node.yml

   → Schedule Pod on a specific node by name using spec.nodeName.

   → Hard assignment (bypasses scheduler). Rarely used — good for learning.

2. pod-for-specific-node-selector.yml

   → Use nodeSelector to schedule on nodes with matching labels.

   → Simple, widely used, great for zonal placement (e.g., disktype: ssd).

Phase 2: Node Affinity (Flexible & Expressive)

Modern, powerful replacement for nodeSelector — supports required and preferred rules.

1. pod-with-required-node-affinity.yml

   → Must run on nodes matching affinity rules (requiredDuringScheduling...).

2. pod-with-preferred-node-affinity.yml

   → Prefer certain nodes, but run elsewhere if needed (preferredDuringScheduling...).

3. pod-with-node-affinity-multiple.yml

   → Combine multiple affinity rules (e.g., match zone AND GPU).

4. pod-with-node-affinity-cannot.yml

   → Example where no node matches → Pod stays Pending (great for troubleshooting).

💡 Key Concept:

• required = hard constraint (like nodeSelector)
• preferred = soft constraint (scheduler tries, but won’t block)

Phase 3: Pod Affinity & Anti-Affinity (Pod-to-Pod Rules)

Control placement based on other Pods — critical for HA and isolation.

1. pod-with-anti-pod-affinity.yml

   → Avoid running on same node/zone as other Pods (e.g., spread replicas).

2. pod-for-anti-affinity.yml

   → Likely a companion Pod used to demonstrate anti-affinity (e.g., deploy two Pods that must be separated).

🎯 Use Cases:

• Anti-affinity: Spread app replicas across nodes/zones → high availability
• Affinity: Co-locate cache + app → low latency