search by tags

for the user

adventures into the land of the command line

taints and tolerations

think of a taint as a bad smell that is added to a node. once a node is tainted pods that don’t declare a toleration for the taint won’t be scheduled to that node.

$ kubectl taint nodes nodename key=value:effect

The key and value can be anything you want and act just like key:value pairs act throughout kubernetes: something matches if it specifies the same key and value.

The effect can be one of:

PreferNoSchedule - tells the scheduler to prefer not to schedule intolerant pods to the tainted node
NoSchedule - prohibits the scheduler from scheduling intolerant pods to the tainted node
NoExecute - tells the scheduler to also evict intolerant pods that are already running on the tainted node

For example, let’s say that we elasticsearch running on a node and we don’t want anything else running there...

$ kubectl taint nodes es-node elasticsearch=false:NoExecute


a toleration is how a pod declares that it can stand the smell of a taint. a toleration for the above taint might look like this. it is declared in the pod spec of your deployment or stateful set.

- key: elasticsearch
  operator: Equal
  value: false
  effect: NoExecute

you can also specify a toleration that will match any taint, for example when you have a daemon set that you would like to be scheduled to every node in your cluster

- operator: Exists
  effect: NoExecute
- operator: Exists
  effect: NoSchedule