And for some reason, after the pod is scheduled on the node, if there is a mismatch between taint and toleration values, the pod will continue to run on the same node. The value of “ NoSchedule” means that if the taint and toleration values do not match, the pod will not be scheduled on the node. It can have values of “ NoSchedule” and “ NoExecute”. It is important to understand the field “effect”. The below is a snippet from the pod specification file. Similarly, the way to specify toleration on pods is using a pod specification file. The syntax to set taint on a node using kubectl command is: kubectl taint nodes :įor this specific example, the command we will run is: kubectl taint nodes SpNode1 specialized=true:NoSchedule If the taint and the toleration do not match, the pod will not be scheduled on the node. If they match, the Kubernetes scheduler goes ahead and schedules the pod on the node. Now what does Kubernetes do? Kubernetes scheduler checks if a node is tainted and checks the pods that have the same toleration level set. The way to ensure that a pod can tolerate the taint on a node is by setting a toleration level on the pod as well. In essence, let’s say, if we taint the node SpNode1 with (specialized=true), the node SpNode1 will only accept the pods that can tolerate the taint (specialized=true). Doing this will ensure the node will not accept any pod that cannot tolerate the taint. Tainting a node essentially means setting a property (key=value) on the node. Let’s apply the concept of Taints and Tolerations and see if it meets our requirement. Simple enough and a common requirement, isn’t it? Let’s see if the concept of Taints and Tolerations will help in meeting the requirement.