Kubernetes: Taints and Tolerations

Reading Time: 4 minutes

Kubernetes provides us the way to customize the scheduling of pods in our own defined way to satisfy some of our business use-cases. These ways are by using node selector, affinity etc. But additional mechanisms were later add that expand this functionality. These are taints and tolerations. Let’s see each of them for what they are and how they work.

What are Taints and Tolerations?

  • We know that NodeSelector and Affinity focus on attracting the pods to a certain set of nodes. On the other hand they are opposite. Taints and Tolerations used to repel a set of pods from the nodes i.e they allow a node to repel a set of pods.
  • In a simpler way we can say that They’re use for restricting which pods can use a certain node. A pod can only be schedule to a node if it tolerates the node’s taints.
  • Taints and Tolerations work together to ensure that pods are not schedule onto inappropriate nodes.Taints are apply on nodes whereas Tolerations are apply on the pods.
  • Taints and Tolerations do not tell the pod to go to a particular node instead it tells the node to only accept pods with certain toleration.

Applying Taints and Tolerations on the nodes:

Tainting a Node:

Taints are apply to a node using kubectl, for example:

Here Minikube is my node name and app is here my key and equals to is here operator. And NoSchedule is taint-effect.

Each taint has an effect associated with it. There are three possible effects that exist :

  1. NoSchedule: which means pods won’t be schedule to the node if they don’t tolerate the taint.
  1. PreferNoSchedule: PreferNoSchedule is a soft version of NoSchedule, meaning the scheduler will try to avoid scheduling the pod to the node, but will schedule it to the node if it can’t schedule it somewhere else.
  1. NoExecute: Unlike NoSchedule and PreferNoSchedule that only affect scheduling, also affects pods already running on the node. If you add a NoExecute taint to a node, pods that are already running on that node and don’t tolerate the NoExecute taint will be evict from the node.

And we can verify if our node is tainted or not by using following command:

Therefore, here the node is tainted.

Tolerate a Pod:

 And now, we have to apply tolerations on the pod. Tolerations can tolerate a specific value by specifying the Equal operator (that’s also the default operator if you don’t specify one), or they can tolerate any value for a specific taint key if you use the Exists operator.

Here is an yaml file applying tolerations inside pod specification:

In this example, any existing nodes would keep running on the tainted node, but no further Pods would be scheduled unless they have the following tolerations fields in their Podspec mentioned above. And then apply this by using following command:

This means if the pod doesn’t match this taint, it can’t be scheduled on this node.

How Pod Toleration match Taint:

  • A toleration “matches” a taint if the keys are the same and the effects are the same
  • if the operator is Equal and the values are equal
  • if the operator is Exists → then value should not be specified
  • if the operator is not specified → it defaults to Equal.

Using Multiple Taints:

It is possible to apply more than one taint to a single node and more than one toleration to a single Pod. Multiple taints and tolerations are use by Kubernetes like a filter. Taint’s matching Pod’s tolerations are ignore. The remaining taint effects are then apply to the Pod. Some of the effects include

  • Kubernetes will not schedule the Pod if at least one non-tolerated taint has a NoSchedule effect.
  • Kubernetes will try not to schedule the Pod on the node if at least one non-tolerated taint has a PreferNoSchedule effect.
  • A NoExecute taint will cause Kubernetes to evict the Pod if it is currently running on the node or will not schedule the Pod the node.

Removing a taint from that node:

Use the following command to untaint a particular node:

And finally verify it by following command:


You can specify tolerationSeconds for a Pod to define how long that Pod stays bound to a failing or unresponsive Node. We can add tolerationSeconds if we want to give how long the pod will stay bound to the node after the taint is added.


After reading this blog, you will now be able to understand how taint and tolerations work with each other. Here we have seen Taint and toleration are useful if you want to work with dedicated nodes. Thanks a lot for being with me till the end.

Happy Learning!

Written by 

Naincy Kumari is a DevOps Consultant at Knoldus Inc. She is always ready to learn new technologies and tools. She loves painting and dancing.