untolerated taint: The node repels this pod and the pod has no matching toleration

Taints mark nodes as unsuitable for pods that do not explicitly accept them. A pod without the matching toleration is filtered out of scheduling, which is the taint working correctly.

Applies to: All Kubernetes versions

What it means

A taint is a property on a node saying "do not schedule here unless you specifically accept this". A toleration on a pod is that acceptance. The scheduler filters out any node whose taints the pod does not tolerate, and reports it in the FailedScheduling message as node(s) had untolerated taint {key: value}. The effect field matters: NoSchedule prevents new placement, PreferNoSchedule is a soft preference, and NoExecute additionally evicts pods already running that do not tolerate it. Some taints are applied automatically by Kubernetes itself, which is why this message often names a taint nobody set by hand.

Most common causes

• Control-plane nodes tainted to keep application workloads off them.
• A specialised node pool — GPU, memory-optimised, spot instances — tainted so only intended workloads land there.
• Automatic taints for node conditions: not ready, unreachable, memory pressure, disk pressure.
• A node cordoned, which applies an unschedulable taint.
• A taint applied during maintenance and never removed.
• A toleration whose key, value, or operator does not exactly match the taint.

How to diagnose it

1. Read which taint is named in the message: kubectl describe pod POD.
2. List taints across nodes: kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints.
3. Compare against the pod's tolerations: kubectl get pod POD -o jsonpath='{.spec.tolerations}'.
4. Check the match carefully — Equal requires the value to match, while Exists matches any value for the key.
5. Determine whether the taint was set deliberately or applied automatically by a node condition.

How to fix it

1. Add the matching toleration if the pod genuinely belongs on those nodes.
2. Remove the taint if it is stale: kubectl taint nodes NODE KEY-.
3. Fix the underlying node condition if the taint was applied automatically — tolerating a disk pressure taint puts the pod on a node that is out of disk.
4. Uncordon a node that was cordoned for maintenance that is finished.
5. Pair tolerations with node affinity. A toleration only permits scheduling on a tainted node; it does not attract the pod there, so specialised workloads usually need both.

Notes

A toleration is permission, not preference. Adding a GPU toleration to a pod does not make it schedule onto GPU nodes — it makes it eligible to, alongside every other node. Node affinity or a node selector is what actually directs it.

Related

• FailedScheduling — The scheduler could not find a suitable node
• node.kubernetes.io/unreachable — The node controller cannot reach the node

Sources

• Kubernetes documentation — Taints and Tolerations
• Kubernetes documentation — Assigning Pods to Nodes
• Kubernetes documentation — Kubernetes Scheduler