Pod affinity and anti-affinity in Kubernetes - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to specify pod affinity for pods with label app=frontend.

Kubernetes

affinity:
  podAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchExpressions:
        - key: app
          operator: In
          values:
          - [1]
      topologyKey: kubernetes.io/hostname

Drag options to blanks, or click blank then click option'

Abackend

Bfrontend

Cdatabase

Dcache

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing a label value that does not match the target pods.

Confusing pod affinity with pod anti-affinity.

The pod affinity requires pods with label app=frontend, so the value must be frontend.

2fill in blank

medium

Complete the code to specify pod anti-affinity to avoid scheduling pods on the same node with label app=database.

Kubernetes

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchLabels:
          app: [1]
      topologyKey: kubernetes.io/hostname

Drag options to blanks, or click blank then click option'

Acache

Bfrontend

Cdatabase

Dworker

Attempts:

3 left

💡 Hint

Common Mistakes

Using the wrong label value that does not match the pods to avoid.

Mixing up pod affinity and anti-affinity.

Pod anti-affinity avoids scheduling pods on nodes with pods labeled app=database, so the value must be database.

3fill in blank

hard

Fix the error in the pod affinity configuration by completing the missing operator.

Kubernetes

affinity:
  podAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchExpressions:
        - key: role
          operator: [1]
          values:
          - frontend
      topologyKey: failure-domain.beta.kubernetes.io/zone

Drag options to blanks, or click blank then click option'

AIn

BExists

CNotIn

DDoesNotExist

Attempts:

3 left

💡 Hint

Common Mistakes

Using Exists or DoesNotExist when values are specified.

Using NotIn which negates the match.

The operator In is used to match pods whose label role is in the specified values list.

4fill in blank

hard

Fill both blanks to create a pod anti-affinity rule that avoids pods with label tier=backend on the same node.

Kubernetes

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: tier
            operator: [1]
            values:
            - [2]
        topologyKey: kubernetes.io/hostname

Drag options to blanks, or click blank then click option'

AIn

Bbackend

Cfrontend

DNotIn

Attempts:

3 left

💡 Hint

Common Mistakes

Using NotIn which would invert the match.

Using the wrong tier value.

The operator In is used with the value backend to specify pods with label tier=backend for anti-affinity.

5fill in blank

hard

Fill all three blanks to define pod affinity that prefers pods with label env=prod and role=frontend on the same zone.

Kubernetes

affinity:
  podAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 50
      podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: env
            operator: [1]
            values:
            - [2]
          - key: role
            operator: [3]
            values:
            - frontend
        topologyKey: failure-domain.beta.kubernetes.io/zone

Drag options to blanks, or click blank then click option'

AIn

Bprod

DNotIn

Attempts:

3 left

💡 Hint

Common Mistakes

Using NotIn which would exclude the desired pods.

Mixing operator types between the two label selectors.

Both operators are In to match the values prod for env and frontend for role.

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