Pod affinity and anti-affinity in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Pod Affinity Basics

What is the main purpose of pod affinity in Kubernetes?

A To schedule pods to run on nodes that already have pods with matching labels, improving locality.

B To automatically scale pods based on CPU usage.

C To prevent pods from running on nodes with certain labels to avoid resource conflicts.

D To restrict pods to run only on nodes with specific hardware capabilities.

💡 Hint

Think about how pods can be placed close to similar pods for better communication.

Pod affinity lets you schedule pods close to other pods with matching labels, which helps reduce network latency and improve performance.

💻 Command Output

intermediate

Pod Anti-Affinity Scheduling Result

Given the following pod anti-affinity rule, what will happen when scheduling a new pod?

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
            - key: app
              operator: In
              values:
                - frontend
        topologyKey: kubernetes.io/hostname

The cluster has nodes with existing pods labeled app=frontend on some nodes.

A The new pod will be scheduled only on nodes that have pods with label app=frontend.

B The new pod will not be scheduled on any node that already runs a pod with label app=frontend.

C The new pod will be scheduled on any node regardless of existing pods.

D The new pod will be scheduled only on nodes without the label app=frontend.

💡 Hint

Anti-affinity means avoiding nodes with certain pods.

This anti-affinity rule prevents scheduling the new pod on nodes that already have pods labeled app=frontend, ensuring they don't co-locate on the same host.

❓ Configuration

advanced

Correct Pod Affinity YAML Configuration

Which YAML snippet correctly configures requiredDuringSchedulingIgnoredDuringExecution pod affinity to schedule pods on nodes with pods labeled role=database?

A

affinity:
  podAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchLabels:
              role: database
          topologyKey: kubernetes.io/hostname

B

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            role: database
        topologyKey: kubernetes.io/hostname

C

affinity:
  podAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            role: database
        topologyKey: kubernetes.io/hostname

D

affinity:
  podAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
            - key: role
              operator: NotIn
              values:
                - database
        topologyKey: kubernetes.io/hostname

💡 Hint

Look for required affinity with matching labels and correct topology key.

Option C correctly uses requiredDuringSchedulingIgnoredDuringExecution with matchLabels to require pods to be scheduled on nodes with pods labeled role=database.

❓ Troubleshoot

advanced

Pod Fails to Schedule Due to Affinity Rules

A pod with the following affinity rule fails to schedule:

affinity:
  podAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            app: backend
        topologyKey: failure-domain.beta.kubernetes.io/zone

What is the most likely cause?

A No existing pods with label app=backend are running in the same zone, so the scheduler cannot place the pod.

B The topologyKey is deprecated and causes the scheduler to ignore the rule.

C The pod affinity rule syntax is invalid and causes a scheduling error.

D The pod is missing resource requests, so affinity rules are ignored.

💡 Hint

Affinity requires matching pods to exist in the specified topology.

The requiredDuringScheduling rule demands the pod be scheduled on a node in the same zone as pods labeled app=backend. If none exist, scheduling fails.

🔀 Workflow

expert

Implementing Pod Anti-Affinity for High Availability

You want to deploy multiple replicas of a critical service so that no two replicas run on the same node to improve availability.

Which pod anti-affinity configuration achieves this?

A

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            app: critical-service
        topologyKey: failure-domain.beta.kubernetes.io/zone

B

affinity:
  podAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            app: critical-service
        topologyKey: kubernetes.io/hostname

C

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchLabels:
              app: critical-service
          topologyKey: failure-domain.beta.kubernetes.io/zone

D

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            app: critical-service
        topologyKey: kubernetes.io/hostname

💡 Hint

To avoid co-locating pods on the same node, use anti-affinity with hostname topology.

Option D uses podAntiAffinity with requiredDuringSchedulingIgnoredDuringExecution and topologyKey kubernetes.io/hostname, ensuring pods do not run on the same node.

Practice

1. What is the main purpose of podAffinity in Kubernetes?

easy

A. To automatically restart pods on failure

B. To prevent pods from running on the same node

C. To limit the number of pods per node

D. To schedule pods close to other pods with matching labels

Solution

1. Step 1: Understand podAffinity concept

   Pod affinity is used to place pods close to other pods that have specific labels, improving communication or resource sharing.

2. Step 2: Compare options with podAffinity purpose

   Only To schedule pods close to other pods with matching labels describes placing pods close to others with matching labels, which matches podAffinity's goal.

3. Final Answer:

   To schedule pods close to other pods with matching labels -> Option D

4. Quick Check:

   podAffinity = place pods close [OK]

Hint: Affinity means placing pods near each other [OK]

Common Mistakes:

• Confusing affinity with anti-affinity
• Thinking affinity limits pods per node
• Mixing affinity with pod restart policies

2. Which of the following is the correct syntax to specify a required pod anti-affinity rule in a pod spec?

easy

A. "podAntiAffinity": {"requiredDuringSchedulingIgnoredDuringExecution": [{"labelSelector": {"matchLabels": {"app": "web"}}, "topologyKey": "kubernetes.io/hostname"}]}

B. "podAntiAffinity": {"preferredDuringSchedulingIgnoredDuringExecution": [{"weight": 100, "podAffinityTerm": {"labelSelector": {"matchLabels": {"app": "web"}}, "topologyKey": "kubernetes.io/hostname"}}]}

C. "podAffinity": {"requiredDuringSchedulingIgnoredDuringExecution": [{"labelSelector": {"matchLabels": {"app": "web"}}, "topologyKey": "kubernetes.io/hostname"}]}

D. "podAffinity": {"preferredDuringSchedulingIgnoredDuringExecution": [{"weight": 50, "podAffinityTerm": {"labelSelector": {"matchLabels": {"app": "web"}}, "topologyKey": "kubernetes.io/zone"}}]}

Solution

1. Step 1: Identify required pod anti-affinity syntax

   Required pod anti-affinity uses podAntiAffinity with requiredDuringSchedulingIgnoredDuringExecution and a label selector plus topology key.

2. Step 2: Match syntax with options

   "podAntiAffinity": {"requiredDuringSchedulingIgnoredDuringExecution": [{"labelSelector": {"matchLabels": {"app": "web"}}, "topologyKey": "kubernetes.io/hostname"}]} correctly uses podAntiAffinity with requiredDuringSchedulingIgnoredDuringExecution and proper labelSelector and topologyKey.

3. Final Answer:

   Correct required pod anti-affinity syntax -> Option A

4. Quick Check:

   Required anti-affinity uses podAntiAffinity + requiredDuringScheduling [OK]

Hint: Required anti-affinity uses podAntiAffinity + requiredDuringScheduling [OK]

Common Mistakes:

• Using podAffinity instead of podAntiAffinity
• Confusing required and preferred rules
• Wrong topologyKey values

3. Given this pod spec snippet, what will happen if a pod with label app: frontend is scheduled?

affinity:
  podAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchLabels:
          app: backend
      topologyKey: kubernetes.io/hostname

medium

A. The pod will be scheduled only if no pod with label app=backend exists

B. The pod will be scheduled on any node regardless of other pods

C. The pod will be scheduled on a node that already runs a pod with label app=backend

D. The pod scheduling will fail due to syntax error

Solution

1. Step 1: Understand required podAffinity behavior

   Required podAffinity means the pod must be placed on a node where pods with matching labels already run, here app=backend.

2. Step 2: Apply to given pod spec

   The pod with label app=frontend requires a node with pods labeled app=backend, so it will schedule only on such nodes.

3. Final Answer:

   The pod will be scheduled on a node that already runs a pod with label app=backend -> Option C

4. Quick Check:

   Required podAffinity = schedule near matching pods [OK]

Hint: Required podAffinity means schedule near matching pods [OK]

Common Mistakes:

• Thinking podAffinity prevents scheduling near pods
• Confusing required and preferred affinity
• Assuming scheduling fails without matching pods

4. You wrote this anti-affinity rule but pods are still scheduled on the same node:

podAntiAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
  - labelSelector:
      matchLabels:
        app: database
    topologyKey: ""

What is the likely cause?

medium

A. Empty topologyKey causes the rule to be ignored

B. Label selector is incorrect syntax

C. Required rules are always ignored by scheduler

D. podAntiAffinity must be under preferredDuringSchedulingIgnoredDuringExecution

Solution

1. Step 1: Check topologyKey usage

   The topologyKey must be a valid node label key like kubernetes.io/hostname. Empty string disables the rule.

2. Step 2: Understand scheduler behavior

   With empty topologyKey, the scheduler ignores the anti-affinity rule, allowing pods on same node.

3. Final Answer:

   Empty topologyKey causes the rule to be ignored -> Option A

4. Quick Check:

   Valid topologyKey needed for anti-affinity [OK]

Hint: topologyKey cannot be empty for anti-affinity rules [OK]

Common Mistakes:

• Leaving topologyKey empty
• Misplacing anti-affinity under preferred instead of required
• Assuming required rules are ignored

5. You want to deploy multiple replicas of a pod with label app: cache so that no two pods run on the same node, but you want the scheduler to try to keep pods in the same zone if possible. Which affinity configuration achieves this?

hard

A. Use podAffinity with requiredDuringSchedulingIgnoredDuringExecution on app: cache and topologyKey: kubernetes.io/hostname only

B. Use podAntiAffinity with requiredDuringSchedulingIgnoredDuringExecution on app: cache and topologyKey: kubernetes.io/hostname, plus podAffinity with preferredDuringSchedulingIgnoredDuringExecution on topologyKey: failure-domain.beta.kubernetes.io/zone

C. Use podAntiAffinity with preferredDuringSchedulingIgnoredDuringExecution on app: cache and topologyKey: kubernetes.io/hostname only

D. Use podAffinity with preferredDuringSchedulingIgnoredDuringExecution on app: cache and topologyKey: failure-domain.beta.kubernetes.io/zone only

Solution

1. Step 1: Prevent pods on same node strictly

   Use podAntiAffinity with requiredDuringSchedulingIgnoredDuringExecution and topologyKey: kubernetes.io/hostname to ensure no two pods run on the same node.

2. Step 2: Prefer pods in same zone

   Add podAffinity with preferredDuringSchedulingIgnoredDuringExecution and topologyKey: failure-domain.beta.kubernetes.io/zone to encourage scheduling pods in the same zone but not strictly.

3. Step 3: Combine both rules

   Use podAntiAffinity with requiredDuringSchedulingIgnoredDuringExecution on app: cache and topologyKey: kubernetes.io/hostname, plus podAffinity with preferredDuringSchedulingIgnoredDuringExecution on topologyKey: failure-domain.beta.kubernetes.io/zone combines strict anti-affinity on node and preferred affinity on zone, matching the requirement.

4. Final Answer:

   Use required podAntiAffinity on hostname and preferred podAffinity on zone -> Option B

5. Quick Check:

   Strict anti-affinity + preferred affinity = Use podAntiAffinity with requiredDuringSchedulingIgnoredDuringExecution on app: cache and topologyKey: kubernetes.io/hostname, plus podAffinity with preferredDuringSchedulingIgnoredDuringExecution on topologyKey: failure-domain.beta.kubernetes.io/zone [OK]

Hint: Use required anti-affinity on node + preferred affinity on zone [OK]

Common Mistakes:

• Using affinity instead of anti-affinity to separate pods
• Using preferred instead of required for strict separation
• Ignoring zone preference