Taints and Tolerations

Taints and tolerations work together to ensure that pods are not scheduled onto inappropriate nodes. They form a powerful mechanism to control which workloads can run on specific nodes.

How Taints and Tolerations Work

Taints mark nodes as unsuitable for certain workloads, while tolerations allow pods to overcome these restrictions. This relationship creates a selective scheduling system where:

Nodes with taints repel pods that don’t have matching tolerations
Pods with tolerations can be scheduled on nodes with matching taints (but aren’t required to be)
Without a matching toleration, pods won’t be scheduled on tainted nodes

Taint Effects

Taints have three possible effects that determine how pods without matching tolerations are treated:

Effect	Behavior for Pods without Matching Toleration
`NoSchedule`	Will not be scheduled on the tainted node
`PreferNoSchedule`	System tries to avoid scheduling on the node, but not guaranteed
`NoExecute`	Won’t be scheduled AND existing pods will be evicted if they lack the toleration

Example: Applying Taints and Tolerations

First, taint a node to mark it for specific workloads:

kubectl taint nodes node1 key=value:NoSchedule

Then, create a pod with a matching toleration:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-toleration
spec:
  tolerations:
  - key: "key"
    operator: "Equal"
    value: "value"
    effect: "NoSchedule"
  containers:
  - name: nginx
    image: nginx

Common Use Cases for Taints and Tolerations

Taints and tolerations are particularly useful for several common cluster management scenarios:

Use Case	Implementation	Benefit
Dedicated Nodes	Taint nodes with `dedicated=purpose:NoSchedule`	Reserve nodes for specific workloads
Special Hardware	Taint GPU nodes with `hardware=gpu:NoSchedule`	Prevent general workloads from consuming specialized resources
Automatic Node Problems	Kubernetes automatically applies taints like `node.kubernetes.io/not-ready`	Prevent scheduling on problematic nodes
Zone Isolation	Taint nodes by zone for controlled scheduling	Implement advanced availability patterns
Gradual Node Decommissioning	Apply `NoExecute` taints with `tolerationSeconds`	Drain nodes gradually for maintenance

Tolerations and Pod Eviction

The NoExecute effect can be combined with tolerationSeconds to control how long a pod can run on a node after a taint is applied:

tolerations:
- key: "node.kubernetes.io/unreachable"
  operator: "Exists"
  effect: "NoExecute"
  tolerationSeconds: 300  # Pod will be evicted after 5 minutes

This allows for graceful pod migration during node problems or maintenance.