Affinity & Topology Spread Constraints

Taints and tolerations push pods away from nodes. This lesson is about the opposite direction: pods expressing where they'd like to land, relative to nodes or to each other.

Node affinity: a richer nodeSelector

nodeAffinity does what nodeSelector does — match pods to nodes by label — but with two levels of commitment:

• requiredDuringSchedulingIgnoredDuringExecution — a hard requirement. No matching node, no scheduling (the pod stays Pending, same as a taint blocking it, just from the opposite direction).
• preferredDuringSchedulingIgnoredDuringExecution — a weighted preference. The scheduler tries, but will place the pod elsewhere rather than leave it Pending.

The "IgnoredDuringExecution" part matters: if a node's labels change after a pod is already running there, that pod is not evicted — affinity is only evaluated at scheduling time, not continuously enforced like a taint's NoExecute effect.

Pod affinity and anti-affinity: relative to other pods, not nodes

Instead of matching node labels, podAffinity/podAntiAffinity match other pods' labels, then place relative to wherever those pods are: affinity co-locates (put my cache next to the service that uses it, same zone or even same node), anti-affinity spreads (don't put two replicas of the same Deployment on the same node — classic availability pattern).

Topology spread constraints

topologySpreadConstraints: maxSkew=1

🖥 node-a

pod-1

pod-2

pod-3

🖥 node-b

pod-4

Topology spread constraints: the newer, more precise tool

podAntiAffinity can spread pods, but its "spread evenly" logic gets awkward with more than two replicas. topologySpreadConstraints says directly what you mean: spread these pods across a given topology key (kubernetes.io/hostname for nodes, topology.kubernetes.io/zone for zones) within maxSkew of each other. For "give me even distribution across nodes/zones," prefer this over podAntiAffinity — it's purpose-built for exactly that job, where anti-affinity is a more general (and clunkier) tool bent toward the same end.

One more field worth knowing: nodeTaintsPolicy. By default it's Ignore, meaning a tainted, unschedulable node still counts as a valid topology domain when the scheduler computes skew — which can leave a constraint unsatisfiable for reasons that have nothing to do with topology at all. Setting it to Honor excludes nodes your pod couldn't land on anyway from that count. (If you did the previous lesson's lab and left k8s-course-worker tainted, this is exactly why this lesson's lab sets nodeTaintsPolicy: Honor too.)

The infrastructure analogy

nodeAffinity is a pod choosing its subnet/AZ by tag, the way you'd pin an instance to a specific placement group. podAntiAffinity and topology spread are what an ASG's spread-across-AZs setting does for you automatically — except here you're expressing it per-workload, not once at the group level, so you can intentionally co-locate one workload while spreading another.

In the lab, you'll apply a topology spread constraint to a small Deployment and confirm its replicas land on different nodes instead of piling onto one.