Kubernetes 101 : Taints, toleration and node affinity

When we have a heterogeneous kubernetes cluster, made up of nodes that vary in terms of power or storage speed for example, we want to schedule the resource-hungry pods on the powerful node and the "normal" pods on the less powerful ones.


A taint is a node label that tells a node to refuse to host pods that don't tolerate its taint.
A pod can define a toleration that specifies that it can tolerate (accept) a "node taint".

A pod defines a toleration for a node's taint in the below format in its Yaml configuration file:  - key=value:effect
The "effect" is the action executed on the pods that don't tolerate the taint of the node.


We tainted our node with a "blue" taint. 
All the pods that tolerate the taint - pods with a shade of blue - can be scheduled on the node, the other pods can't be scheduled on the node. 

Displaying the kubernetes cluster nodes:

We display the nodes in the cluster using the below command:

Assigning a label to a node:

We can assign a label to a node using the below command:

Assigning a "Taint" to a node:

we can assign the taint "reserved=games:NoShedule" to all the nodes with "graphic=nvidia" label using the below command:

Now the nodes with the "graphic=nvidia" label repel all the pods that don't tolerate the "reserved=games:NoShedule" taint.

We check that the taint has been assigned to a node using the below command:

Deploying the "tolerating" pods:

Below is a deployment that spawns three replicas of pods that have a toleration for the taint "reserved=games:NoShedule":

The "NoShedule" is the action executed for the pods that don't tolerate the taint "reserved=games:NoShedule".


When a pod has a toleration for a taint on a node, it doesn't mean that the pod is going to be scheduled on that node.
To ensure that, we would need to add a node affinity to force all the "games" pods on the node tainted with "reserved=games:NoShedule"

To achieve that we would need to change our deployment as below:


Leave as a comment: