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

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Node Affinity Types

Which of the following best describes the difference between requiredDuringSchedulingIgnoredDuringExecution and preferredDuringSchedulingIgnoredDuringExecution in Kubernetes node affinity?

A requiredDuringSchedulingIgnoredDuringExecution means pods prefer matching nodes but can schedule elsewhere; preferredDuringSchedulingIgnoredDuringExecution means pods must be scheduled on matching nodes.

B requiredDuringSchedulingIgnoredDuringExecution means pods must be scheduled on matching nodes; preferredDuringSchedulingIgnoredDuringExecution means pods prefer matching nodes but can schedule elsewhere if none match.

C Both mean pods must be scheduled on matching nodes, but preferredDuringSchedulingIgnoredDuringExecution also enforces node labels at runtime.

D Both mean pods prefer matching nodes, but requiredDuringSchedulingIgnoredDuringExecution ignores node labels during scheduling.

💡 Hint

Think about what happens if no nodes match the affinity rules.

requiredDuringSchedulingIgnoredDuringExecution enforces a hard rule: pods will only schedule on nodes that match the criteria. preferredDuringSchedulingIgnoredDuringExecution is a soft preference: the scheduler tries to place pods on matching nodes but will schedule elsewhere if needed.

💻 Command Output

intermediate

Output of Pod Scheduling with Node Affinity

Given a Kubernetes cluster with nodes labeled zone=us-east-1a and zone=us-east-1b, and a pod spec with this node affinity:

{
  "requiredDuringSchedulingIgnoredDuringExecution": {
    "nodeSelectorTerms": [
      {"matchExpressions": [{"key": "zone", "operator": "In", "values": ["us-east-1a"]}]}
    ]
  }
}

What will be the output of kubectl get pods -o wide regarding the node the pod is scheduled on?

A The pod will be scheduled only on a node labeled zone=us-east-1a.

B The pod will be scheduled on any node regardless of zone label.

C The pod will fail to schedule because no nodes match the affinity.

D The pod will be scheduled on a node labeled zone=us-east-1b.

💡 Hint

Check the meaning of requiredDuringSchedulingIgnoredDuringExecution.

The requiredDuringSchedulingIgnoredDuringExecution affinity restricts scheduling to nodes with the specified label. So the pod will only run on nodes labeled zone=us-east-1a.

❓ Configuration

advanced

Correct Node Anti-Affinity YAML

Which of the following YAML snippets correctly configures a pod to avoid scheduling on nodes that already run pods with label app=frontend using requiredDuringSchedulingIgnoredDuringExecution node anti-affinity?

A

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

B

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

C

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

D

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

💡 Hint

Remember that node anti-affinity uses podAntiAffinity, not nodeAffinity or podAffinity.

Node anti-affinity to avoid nodes running pods with certain labels uses podAntiAffinity with requiredDuringSchedulingIgnoredDuringExecution. Option D correctly uses this syntax.

❓ Troubleshoot

advanced

Pod Fails to Schedule Due to Node Affinity

A pod with this node affinity fails to schedule:

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: disk
          operator: In
          values:
          - ssd

What is the most likely reason?

A No nodes in the cluster have the label <code>disk=ssd</code>.

B The pod spec is missing a container image.

C The pod is trying to schedule on nodes labeled <code>disk=hdd</code> which conflicts with affinity.

D The nodeAffinity field is misspelled and ignored by the scheduler.

💡 Hint

Check if any nodes have the required label.

If no nodes have the label disk=ssd, the requiredDuringSchedulingIgnoredDuringExecution affinity cannot be satisfied, so the pod will not schedule.

✅ Best Practice

expert

Best Practice for High Availability Using Node Anti-Affinity

You want to deploy multiple replicas of a critical service to ensure high availability. Which node anti-affinity configuration best helps spread pods across different nodes to avoid single points of failure?

A Use <code>preferredDuringSchedulingIgnoredDuringExecution</code> pod affinity with <code>topologyKey: kubernetes.io/hostname</code> to prefer pods on the same node.

B Use <code>preferredDuringSchedulingIgnoredDuringExecution</code> pod anti-affinity with <code>topologyKey: kubernetes.io/hostname</code> to softly prefer pods on different nodes.

C Use <code>requiredDuringSchedulingIgnoredDuringExecution</code> pod anti-affinity with <code>topologyKey: kubernetes.io/hostname</code> to force pods on different nodes.

D Use <code>requiredDuringSchedulingIgnoredDuringExecution</code> node affinity with <code>topologyKey: failure-domain.beta.kubernetes.io/zone</code> to schedule all pods in the same zone.

💡 Hint

Think about how to guarantee pods do not land on the same node.

Using requiredDuringSchedulingIgnoredDuringExecution pod anti-affinity with topologyKey: kubernetes.io/hostname ensures pods are scheduled on different nodes, improving availability by avoiding single-node failure.

Practice

1. What does nodeAffinity in Kubernetes primarily control?

easy

A. Which nodes a pod can be scheduled on based on node labels

B. The order in which pods start in a deployment

C. The network policies applied to pods

D. The resource limits of a pod

Solution

1. Step 1: Understand nodeAffinity purpose

   Node affinity is used to specify rules about which nodes a pod can run on, based on labels assigned to nodes.

2. Step 2: Compare options to nodeAffinity function

   Options B, C, and D relate to pod startup order, network policies, and resource limits, which are unrelated to node affinity.

3. Final Answer:

   Which nodes a pod can be scheduled on based on node labels -> Option A

4. Quick Check:

   nodeAffinity controls pod placement on nodes [OK]

Hint: Node affinity = pod placement by node labels [OK]

Common Mistakes:

• Confusing node affinity with pod resource limits
• Thinking node affinity controls pod startup order
• Mixing node affinity with network policies

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

easy

A. "nodeAffinity": {"preferredDuringSchedulingIgnoredDuringExecution": [{"weight": 1, "preference": {"matchExpressions": [{"key": "disktype", "operator": "In", "values": ["ssd"]}]}}]}

B. "podAffinity": {"requiredDuringSchedulingIgnoredDuringExecution": {"labelSelector": {"matchLabels": {"disktype": "ssd"}}}}

C. "nodeSelector": {"disktype": "ssd"}

D. "nodeAffinity": {"requiredDuringSchedulingIgnoredDuringExecution": {"nodeSelectorTerms": [{"matchExpressions": [{"key": "disktype", "operator": "In", "values": ["ssd"]}]}]}}

Solution

1. Step 1: Identify required node affinity syntax

   Required node affinity uses the key requiredDuringSchedulingIgnoredDuringExecution with nodeSelectorTerms and matchExpressions to specify node labels.

2. Step 2: Check options for correct structure

   "nodeAffinity": {"requiredDuringSchedulingIgnoredDuringExecution": {"nodeSelectorTerms": [{"matchExpressions": [{"key": "disktype", "operator": "In", "values": ["ssd"]}]}]}} matches the required node affinity syntax. "nodeAffinity": {"preferredDuringSchedulingIgnoredDuringExecution": [{"weight": 1, "preference": {"matchExpressions": [{"key": "disktype", "operator": "In", "values": ["ssd"]}]}}]} is preferred affinity, C is nodeSelector (different syntax), and D is pod affinity, not node affinity.

3. Final Answer:

   "nodeAffinity": {"requiredDuringSchedulingIgnoredDuringExecution": {"nodeSelectorTerms": [{"matchExpressions": [{"key": "disktype", "operator": "In", "values": ["ssd"]}]}]}} -> Option D

4. Quick Check:

   Required node affinity uses requiredDuringSchedulingIgnoredDuringExecution [OK]

Hint: Required node affinity uses requiredDuringSchedulingIgnoredDuringExecution [OK]

Common Mistakes:

• Confusing preferred and required affinity syntax
• Using podAffinity instead of nodeAffinity
• Mixing nodeSelector with nodeAffinity syntax

3. Given this pod spec snippet, what will happen if a node has label zone: us-east-1a but no label disk: ssd?

{
  "affinity": {
    "nodeAffinity": {
      "requiredDuringSchedulingIgnoredDuringExecution": {
        "nodeSelectorTerms": [
          {
            "matchExpressions": [
              {"key": "zone", "operator": "In", "values": ["us-east-1a"]},
              {"key": "disk", "operator": "In", "values": ["ssd"]}
            ]
          }
        ]
      }
    }
  }
}

medium

A. The pod will be scheduled only if preferredDuringScheduling is set

B. The pod will not be scheduled on the node because it lacks the required disk label

C. The pod will be scheduled but with a warning

D. The pod will be scheduled because the zone label matches

Solution

1. Step 1: Analyze required node affinity conditions

   Required node affinity means all match expressions must be true for scheduling. The node must have both zone: us-east-1a and disk: ssd labels.

2. Step 2: Check node labels against requirements

   The node has zone: us-east-1a but lacks disk: ssd. This fails the required condition, so the pod cannot be scheduled there.

3. Final Answer:

   The pod will not be scheduled on the node because it lacks the required disk label -> Option B

4. Quick Check:

   Required affinity needs all labels matched [OK]

Hint: Required affinity means all labels must match [OK]

Common Mistakes:

• Assuming partial label match is enough
• Confusing required with preferred affinity
• Thinking pod schedules with warnings on missing labels

4. You wrote this pod spec with pod anti-affinity but pods are still scheduled on the same node. What is the likely error?

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        labelSelector:
          matchLabels:
            app: myapp
        topologyKey: "kubernetes.io/hostname"

medium

A. Incorrect labelSelector syntax causes failure

B. Missing nodeSelector in the pod spec

C. Using preferred instead of required anti-affinity allows scheduling on same node

D. topologyKey should be set to "zone" instead of hostname

Solution

1. Step 1: Understand pod anti-affinity types

   Preferred anti-affinity suggests avoiding co-location but does not enforce it strictly. Required anti-affinity enforces pods not to be scheduled together.

2. Step 2: Analyze the pod spec anti-affinity type

   The spec uses preferredDuringSchedulingIgnoredDuringExecution, which is a soft rule. This allows pods to be scheduled on the same node if needed.

3. Final Answer:

   Using preferred instead of required anti-affinity allows scheduling on same node -> Option C

4. Quick Check:

   Preferred anti-affinity is a soft rule [OK]

Hint: Preferred anti-affinity is soft; use required to enforce [OK]

Common Mistakes:

• Confusing preferred and required anti-affinity
• Assuming labelSelector syntax is wrong without checking
• Thinking topologyKey must be zone for anti-affinity

5. You want to ensure pods with label app=frontend never run on the same node as pods with label app=backend. Which affinity configuration achieves this?

hard

A. Use podAntiAffinity with requiredDuringSchedulingIgnoredDuringExecution and labelSelector matching app=backend

B. Use nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution and labelSelector matching app=backend

C. Use podAffinity with preferredDuringSchedulingIgnoredDuringExecution and labelSelector matching app=backend

D. Use nodeSelector with label app=backend

Solution

1. Step 1: Identify requirement to prevent co-location of pods

   Pod anti-affinity prevents pods from running on the same node as other pods matching certain labels.

2. Step 2: Choose required anti-affinity for strict enforcement

   Using requiredDuringSchedulingIgnoredDuringExecution enforces pods never co-locate on the same node.

3. Step 3: Match labelSelector to pods to avoid

   The labelSelector should match pods with app=backend to prevent frontend pods from scheduling on same node.

4. Final Answer:

   Use podAntiAffinity with requiredDuringSchedulingIgnoredDuringExecution and labelSelector matching app=backend -> Option A

5. Quick Check:

   Pod anti-affinity + required = strict pod separation [OK]

Hint: Use required podAntiAffinity to strictly separate pods [OK]

Common Mistakes:

• Using nodeAffinity instead of podAntiAffinity for pod separation
• Using preferred instead of required anti-affinity for strict rules
• Confusing podAffinity with podAntiAffinity