Understanding Kubernetes Taints and Their Effects

techhadoop kubernetes

Kubernetes Taints

Taints are a mechanism that allow a node to repel certain pods from being scheduled on it. They work together with tolerations (defined on pods) to control which pods can run on which nodes.

The core idea

A taint marks a node as “special” or “restricted.” Only pods that explicitly tolerate that taint will be scheduled there. Everything else is kept away.

Taint structure

A taint has three parts:

key=value:effect
  • key — a label-like identifier (e.g. dedicated, gpu)
  • value — optional qualifier (e.g. true, high-memory)
  • effect — what happens to pods that don’t tolerate it
The three effects
EffectBehavior
NoScheduleNew pods won’t be scheduled on the node. Existing pods stay.
PreferNoScheduleKubernetes tries to avoid scheduling pods here, but will if necessary.
NoExecuteNew pods won’t be scheduled AND existing non-tolerating pods are evicted.
Adding and removing taints
# Add a taint
kubectl taint nodes node1 dedicated=gpu:NoSchedule
# Remove a taint (note the trailing -)
kubectl taint nodes node1 dedicated=gpu:NoSchedule-
Tolerations (the pod side)

A pod opts in to a tainted node by declaring a toleration in its spec:

spec:
  tolerations:
    - key: "dedicated"
      operator: "Equal"
      value: "gpu"
      effect: "NoSchedule"

A toleration with operator: Exists matches any value for that key:

tolerations:
  - key: "dedicated"
    operator: "Exists"
    effect: "NoSchedule"
Common real-world use cases

Dedicated nodes — Reserve a node exclusively for a team or workload (e.g. GPU nodes for ML jobs). Taint the node; only ML pods carry the toleration.

Node issues — Kubernetes itself auto-taints nodes when they’re unhealthy (e.g. node.kubernetes.io/not-ready:NoExecute), causing pods to be evicted.

Control plane isolation — Master/control-plane nodes are tainted by default (node-role.kubernetes.io/control-plane:NoSchedule) so regular workloads don’t land there.

Spot/preemptible nodes — Taint spot instances so only fault-tolerant workloads with the matching toleration run there.

Taints vs. Node Affinity

These are related but different tools:

  • Taints/Tolerations → node repels pods (node-driven, opt-in)
  • Node Affinity → pod seeks nodes (pod-driven, attraction-based)

They’re often used together: taint a node to keep most pods off, and use node affinity on the right pods to actively pull them toward it.

Leave a Reply