Kubernetes Taints and Tolerations: Repelling Pods
Taints act like 'No Trespassing' signs on Kubernetes nodes, repelling pods. Tolerations are the keys that let specific pods ignore those signs. Use this to reserve nodes for special hardware or critical workloads, preventing general pods from landing there.
Why it exists
To give cluster administrators control over which pods can run on which nodes. Without this, the scheduler might place a general-purpose web server on an expensive GPU node, wasting resources. Taints provide a mechanism to reserve nodes for specific workloads by repelling pods that are not explicitly allowed.
The mental model
Think of a taint as a "No Trespassing" sign you put on a node. By default, no pod can enter. A toleration is a special key that a pod carries, allowing it to ignore a specific "No Trespassing" sign and get scheduled on that node. It's a gatekeeping mechanism, not an invitation.
How it works
You apply a taint to a node using a key, a value, and an effect. The three effects are: NoSchedule (new pods without a matching toleration won't be scheduled), PreferNoSchedule (the scheduler will try to avoid placing pods without a toleration), and NoExecute (any running pods without a matching toleration will be evicted). A Pod's spec must include a toleration that matches the taint's key, value, and effect to be placed on the node.
When to use it
Use taints and tolerations to dedicate nodes for specific purposes. This is common for nodes with special hardware like GPUs, for isolating critical monitoring or logging daemons, or for ensuring that only certain applications can run on nodes with higher security requirements. Kubernetes itself uses taints for node conditions like being unreachable or out of disk space.
When not to use it
Do not use taints and tolerations as your primary mechanism for attracting pods to a set of nodes. While they are often used with node affinity to achieve this, their main purpose is repulsion. If you just want to express a preference for a node, nodeAffinity is the correct tool. Using only taints can lead to complex scheduling logic.
One canonical example
To reserve a node for GPU workloads, you would taint the node: kubectl taint nodes node1 gpu=true:NoSchedule. Then, in your machine learning pod's YAML definition, you would add a toleration: tolerations: - key: "gpu" operator: "Equal" value: "true" effect: "NoSchedule". Now, only pods with this specific toleration can be scheduled on node1.
Interview question
To prevent general-purpose pods from being scheduled on nodes reserved for specialized, high-security workloads, which Kubernetes mechanism is most appropriate?
- a.Applying node affinity rules to the specialized nodes.
- b.Implementing taints on the specialized nodes.Correct
- c.Setting resource quotas on the specialized nodes.
- d.Utilizing pod anti-affinity for the general-purpose pods.
Why? this is the answer
Taints are designed to repel pods from nodes, acting as a 'No Trespassing' sign that prevents general pods from being scheduled unless they have a matching toleration. Node affinity, conversely, is used to attract pods to specific nodes, not to keep others away.
Just read this? Test yourself on what you have been reading.
Read the original → kubernetes.io
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles