What are Kubernetes Taints and Tolerations?
Learn how Kubernetes taints repel Pods and tolerations permit them past that repulsion, including NoSchedule vs NoExecute effects.
Expected Interview Answer
A taint is a marker applied to a node that repels Pods from being scheduled onto it unless the Pod explicitly tolerates that taint, and a toleration is a matching declaration on the Pod that allows — but does not force — it to be scheduled there.
A taint has a key, an optional value, and an effect: NoSchedule prevents new Pods without a matching toleration from being placed on the node at all, PreferNoSchedule is a soft version the scheduler tries to avoid but will use if necessary, and NoExecute both prevents new scheduling and evicts any already-running Pods on that node that lack the matching toleration. Tolerations live on the Pod spec and must match a taint’s key, value, and effect (or use the Exists operator to match any value) for the Pod to be allowed onto — or kept running on — that tainted node. Taints and tolerations solve the opposite problem from node affinity: affinity is the Pod expressing a preference for certain nodes, whereas taints are the node actively repelling Pods, and only Pods that explicitly opt in via a toleration get past the repulsion — the two mechanisms are commonly combined for reliable dedicated-node scheduling. Typical uses include dedicating GPU nodes to ML workloads, keeping general workloads off control-plane nodes, and using NoExecute taints with tolerationSeconds to gracefully drain Pods off a node reporting NotReady or under memory pressure.
- Reserves specialized or expensive nodes for only the workloads that need them
- Keeps regular workloads off control-plane or dedicated infrastructure nodes
- Enables automatic, graceful eviction from unhealthy nodes via NoExecute
- Gives fine-grained control that complements node affinity rather than duplicating it
AI Mentor Explanation
A taint is like a groundsman posting a sign at the nets saying 'reserved for national squad only' — no other player may use those nets unless they hold a specific pass. A toleration is that exact pass a national-squad player carries, letting them walk past the sign and use the nets despite the restriction everyone else faces. A stricter version of the sign might say 'anyone currently practicing here without a pass must leave immediately' — matching a NoExecute taint that evicts non-tolerating players even mid-session. This is the opposite direction from choosing a preferred net — here the facility actively repels players unless they carry the right pass.
Step-by-Step Explanation
Step 1
Taint the node
Apply a taint with a key, value, and effect (NoSchedule, PreferNoSchedule, or NoExecute) to repel Pods.
Step 2
Add a matching toleration
Only Pods with a toleration matching that key/value/effect (or using Exists) are permitted onto the node.
Step 3
Scheduler enforces at placement
NoSchedule/PreferNoSchedule block or discourage new placement; unmatched Pods are simply not scheduled there.
Step 4
NoExecute evicts running Pods
Pods already running without a matching toleration are evicted, optionally after a tolerationSeconds grace period.
What Interviewer Expects
- Understanding that taints repel Pods while tolerations permit them past the repulsion
- Knowledge of the three taint effects and how NoExecute differs from NoSchedule
- Ability to contrast taints/tolerations with node affinity (repulsion vs preference)
- Awareness of real use cases like control-plane isolation and dedicated GPU nodes
Common Mistakes
- Confusing taints/tolerations with node affinity (they solve opposite-direction problems)
- Assuming a toleration forces a Pod onto the tainted node rather than just permitting it
- Forgetting NoExecute can evict already-running Pods, not just block new scheduling
- Not knowing tolerationSeconds can delay eviction for graceful draining
Best Answer (HR Friendly)
“Taints let us mark a node as off-limits by default, and tolerations are what a specific workload declares to be allowed onto that node anyway. It is the opposite direction from node affinity — instead of a Pod choosing a node it likes, the node is actively repelling Pods, which is exactly how we keep general workloads off control-plane nodes or reserve expensive GPU machines for the workloads that actually need them.”
Code Example
# Taint a GPU node so only GPU workloads are scheduled there
kubectl taint nodes gpu-node-1 hardware=gpu:NoSchedule
# Pod spec that tolerates the taint
# spec:
# tolerations:
# - key: "hardware"
# operator: "Equal"
# value: "gpu"
# effect: "NoSchedule"
# Remove the taint later
kubectl taint nodes gpu-node-1 hardware=gpu:NoSchedule-Follow-up Questions
- What is the difference between NoSchedule, PreferNoSchedule, and NoExecute?
- How do taints and tolerations differ from node affinity in intent?
- What does tolerationSeconds control on a NoExecute taint?
- Why do control-plane nodes ship with a taint by default?
MCQ Practice
1. What does a taint on a node do by default?
A taint marks a node to repel Pods; only Pods with a matching toleration are permitted to be scheduled there.
2. Which taint effect can evict already-running Pods that lack a matching toleration?
NoExecute both blocks new scheduling and evicts currently running Pods on the node that do not tolerate it.
3. How do taints/tolerations differ conceptually from node affinity?
Taints/tolerations work in the opposite direction from affinity: the node actively repels Pods unless they explicitly tolerate it, whereas affinity is the Pod expressing a preference for certain nodes.
Flash Cards
What is a taint? — A marker on a node that repels Pods unless they have a matching toleration.
What is a toleration? — A Pod-level declaration permitting it onto a node with a matching taint.
Which taint effect evicts running Pods? — NoExecute — it evicts non-tolerating Pods already on the node.
Taints/tolerations vs node affinity? — Taints repel Pods by default; affinity expresses a Pod's preference toward nodes — opposite directions.