DevOpsInterview.Cloud
Kubernetes

Taints Tolerations and Node Affinity - Quick Guide

2 min read

Scheduling questions are a staple in Kubernetes interviews because they separate people who've memorized YAML fields from people who understand why the scheduler behaves the way it does. Taints, tolerations, and node affinity get asked together constantly, and most candidates can define each one but can't explain how they relate.

The answer interviewers want

Think of it like nightclub security. A taint is the bouncer saying "you can't come in" - it's applied to a node and repels pods by default. A toleration is the VIP pass a pod carries that lets it get past that specific bouncer. Node affinity is different: it's your own preference for which club you want to go to, expressed from the pod's side, with no bouncer involved.

The practical split in production: use taints to isolate specialized hardware, like keeping regular workloads off GPU nodes. You taint the GPU nodes, and only pods with the matching toleration can land there. Use node affinity for placement preferences that aren't about exclusion, like preferring pods run in the same availability zone to cut latency or egress cost.

The detail that trips people up, and the one interviewers are actually listening for: taints and tolerations are a pair. A taint on a node means nothing without a toleration on the pod to match it, and a toleration without a matching taint does nothing either. They only function together. Node affinity works alone. It's a rule you set on the pod spec about where it wants to go, with no corresponding node-side object required.

Why interviewers ask this

They're checking whether you understand scheduling as a system of repulsion versus attraction, not just a list of API fields. Anyone can recite "taints repel, affinity attracts." Fewer people can explain that taints/tolerations form a required pair while affinity is a standalone preference, and that distinction is what separates surface-level knowledge from someone who's actually configured node isolation in a real cluster.

Follow-ups to expect

How would you keep regular workloads completely off your GPU nodes? Taint the GPU nodes and only apply the matching toleration to pods that actually need GPUs, since taints default to exclusion.

Would you use affinity instead of a taint for that? No, affinity is a preference, not a guarantee of exclusion, so it's the wrong tool when you need hard isolation like GPU nodes.

What happens if you add a toleration but there's no matching taint? Nothing, the toleration only has an effect when it matches an actual taint on a node, since the two work as a pair.

The common wrong answer

Most candidates describe all three as roughly the same idea, "ways to control pod placement," and leave it there. That misses the actual mechanism: taints and tolerations are a repel/permit pair that requires both sides to exist, while node affinity is a one-sided attraction rule with no node-side counterpart. Glossing over that pairing is the tell that someone hasn't actually debugged a scheduling issue in production.

Prefer it spoken? Watch the 30-second answer on YouTube

More Kubernetes questions