Kubernetes · Orchestration under pressure

How do node and pod affinity/anti-affinity work?

HardaffinityschedulingtopologyUpdated Oct 2026

Short answer

Node affinity constrains which nodes a pod can use. Pod affinity and anti-affinity constrain placement relative to other pods, usually by topology key such as zone or hostname.

Node affinity replaces and extends nodeSelector with required and preferred rules. Pod affinity attracts pods to nodes that already run matching pods, while pod anti-affinity repels them. The topologyKey defines the failure domain, for example kubernetes.io/hostname for one pod per node or topology.kubernetes.io/zone for zone spreading.

requiredDuringSchedulingIgnoredDuringExecution is a hard constraint and can leave pods pending
preferredDuringSchedulingIgnoredDuringExecution is a soft weight and can be ignored
Anti-affinity with required rules multiplies scheduling cost at scale
topologySpreadConstraints often express even spreading more simply
Affinity is evaluated at scheduling time and ignored afterwards, so it does not evict running pods

yaml

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            app: api
        topologyKey: kubernetes.io/hostname
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        preference:
          matchExpressions:
            - key: node-pool
              operator: In
              values: ["general"]

Hard rule: one api pod per node. Soft rule: prefer the general node pool.

Hard anti-affinity with a small node pool is a classic cause of pending pods. Prefer topology spread constraints for spreading, use preferred rules where possible, and verify that enough eligible nodes exist for the required replica count during failures and drains.

Affinity rules are not a security control. For isolation, combine taints, network policies and admission control; scheduling hints alone do not prevent co-location of untrusted workloads.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

1What is the difference between required and preferred affinity?
2How does topologyKey change the meaning of anti-affinity?
3Why can hard anti-affinity cause pending pods?
4When would topologySpreadConstraints be better?

Say it in the interview

Node affinity controls which nodes a pod can land on, while pod affinity and anti-affinity control co-location with other pods. The topology key defines the failure domain, so hostname means one per node and zone means one per zone. Hard rules can strand pods when capacity is tight, so I prefer spreading constraints or preferred rules unless the requirement is absolute. I also remember affinity is only evaluated during scheduling, not continuously.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Kubernetes mock interview and get scored feedback on depth, clarity and confidence.

Start a free Kubernetes interview Browse all questions

Follow-ups you should expect

Related questions

Now say it out loud.