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.