Pod Affinity and Anti-Affinity

   What is Pod Affinity? Pod Affinity is a Kubernetes scheduling concept that allows you to tell the scheduler: “Hey, I want this pod t...

 

 What is Pod Affinity?

Pod Affinity is a Kubernetes scheduling concept that allows you to tell the scheduler:

“Hey, I want this pod to be placed on the same node (or close to) another pod that meets certain criteria.”

It’s about grouping pods together—either on the same node or in the same topology domain (like the same availability zone or region).

---

 Types of Affinity

There are two types of affinity/anti-affinity in Kubernetes:

Type	Meaning
Pod Affinity	"I want to be scheduled with another pod."
Pod Anti-Affinity	"I want to avoid being scheduled with another pod."

---

🧠 Use Case Example

Imagine you have:

• A frontend pod

• A backend pod

You can use pod affinity to ensure that the frontend and backend pods are scheduled on the same node (or same zone) for faster communication.

---

🛠️ Sample Pod Affinity YAML

affinity:
  podAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
            - key: "app"
              operator: In
              values:
                - backend
        topologyKey: "kubernetes.io/hostname"

What does this mean?

• It says: "Schedule this pod on the same node (topologyKey: hostname) as a pod with label app=backend".

• requiredDuringSchedulingIgnoredDuringExecution = Hard requirement for scheduling.

---

✨ Optional vs Required

• **requiredDuringSchedulingIgnoredDuringExecution**: must be fulfilled, or the pod won’t be scheduled.

• **preferredDuringSchedulingIgnoredDuringExecution**: scheduler tries to fulfill, but it’s not mandatory.

---

📍 Common topologyKey Values

Key	Meaning
kubernetes.io/hostname	Same node
topology.kubernetes.io/zone	Same availability zone
topology.kubernetes.io/region	Same region

---

🚫 Pod Anti-Affinity Example

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            app: frontend
        topologyKey: "kubernetes.io/hostname"

This tells the scheduler: "Don't put two frontend pods on the same node."

---

✅ Real-World Use Cases

• Grouping pods that talk frequently (low latency).

• Spreading replicas across zones (via anti-affinity).

• Ensuring co-location for performance or policy needs.

🧠 SCENARIO

Let's imagine:

• You have a frontend pod running.

• You want to schedule another pod:

  • Using Pod Affinity: On the same node as frontend pod.

  • Using Pod Anti-Affinity: On a different node than frontend pod.

---

1️⃣ STEP 1: Create a Frontend Pod

# frontend-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: frontend
  labels:
    app: frontend
spec:
  containers:
  - name: nginx
    image: nginx

This pod will be scheduled on any node, but it’s labeled as app=frontend.

---

📌 Now, Let’s Visualize

+-----------------------+
| NODE-1               |
|  - frontend pod       |
+-----------------------+

+-----------------------+
| NODE-2               |
|  (empty)              |
+-----------------------+

---

2️⃣ STEP 2: Pod Affinity – Schedule Another Pod on the Same Node as Frontend

# affinity-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: sidecar
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
              - key: app
                operator: In
                values:
                  - frontend
          topologyKey: "kubernetes.io/hostname"
  containers:
    - name: busybox
      image: busybox
      command: ["sleep", "3600"]

✅ What happens here?

• Scheduler searches for a node that already has a pod labeled app=frontend.

• It places sidecar pod on that node.

---

✅ Diagram – After Affinity Scheduling

sql
+-----------------------+
| NODE-1               |
|  - frontend pod       |
|  - sidecar pod (affinity) |
+-----------------------+

+-----------------------+
| NODE-2               |
|  (empty)              |
+-----------------------+

---

3️⃣ STEP 3: Pod Anti-Affinity – Avoid Scheduling on the Same Node as Frontend

# anti-affinity-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: logger
spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
              - key: app
                operator: In
                values:
                  - frontend
          topologyKey: "kubernetes.io/hostname"
  containers:
    - name: busybox
      image: busybox
      command: ["sleep", "3600"]

🔄 What happens here?

• Scheduler looks for a node that does NOT have any pod with label app=frontend.

• It places logger on a different node.

---

🚫 Anti-Affinity Result

+-----------------------+
| NODE-1               |
|  - frontend pod       |
+-----------------------+

+-----------------------+
| NODE-2               |
|  - logger pod (anti-affinity) |
+-----------------------+

---

🎨 Summary Diagram (Side-by-Side)

            +-----------------------+             +-----------------------+
 AFFINITY   | NODE-1               |   ANTI-AFF.  | NODE-1               |
            |  - frontend          |             |  - frontend          |
            |  - sidecar           |             |                       |
            +-----------------------+             +-----------------------+
            | NODE-2               |             | NODE-2               |
            |                      |             |  - logger            |
            +-----------------------+             +-----------------------+

---

🔁 Bonus: Multiple Frontend Pods (for anti-affinity)

If you deploy multiple frontend pods, and you use anti-affinity, Kubernetes will try to spread them across nodes. That’s how people often achieve high availability.

---

💡 TopologyKey Reference

• "kubernetes.io/hostname" → same node

• "topology.kubernetes.io/zone" → same zone (used in multi-AZ setups)

• "topology.kubernetes.io/region" → same region