{"id":6190,"date":"2021-05-11T18:39:51","date_gmt":"2021-05-11T13:09:51","guid":{"rendered":"https:\/\/opstree.com\/blog\/\/?p=6190"},"modified":"2021-05-12T17:11:08","modified_gmt":"2021-05-12T11:41:08","slug":"taints-and-tolerations-usage-with-node-selector-in-kubernetes-scheduling","status":"publish","type":"post","link":"https:\/\/opstree.com\/blog\/2021\/05\/11\/taints-and-tolerations-usage-with-node-selector-in-kubernetes-scheduling\/","title":{"rendered":"Taints and Tolerations Usage with Node Selector in Kubernetes Scheduling"},"content":{"rendered":"\n

Earlier, while writing deployment files in k8s, I found that the pods were getting scheduled in any random node. The pods of small deployments got scheduled in large nodes, due to which large deployment pods were staying in a pending state. Therefore, I had to delete the small deployment pods, so that the large deployment pods could get scheduled in that particular node.

One day, I decided to get rid of this problem. While looking for a solution and exploring about Kubernetes, I got to know about Node taints and pod tolerations in Kubernetes. Here, in this blog, I’ll talk about node taints and pod toleration and how we can use it with nodeselector in kubernetes deployments.<\/p>\n\n\n\n\n\n\n\n

Node taints <\/h3>\n\n\n\n

Taint is a property of a node(applied to nodes only)<\/em><\/strong> that allows you to repel a set of pods unless those pods explicitly tolerate the node taint.
In simple words, if we apply taints to a node it will create a restriction shield around the node which will prevent the pods to schedule inside that node.<\/p>\n\n\n\n

\"\"
Node taint<\/figcaption><\/figure>\n\n\n\n

When I got to know about Node taints, the first question that came to my mind was- In Kubernetes,<\/em> we have 2 nodes Master & Worker and my pod always gets scheduled in the worker node but why not in the master node. Are there any taints applied to the master node<\/em>?

The answer is yes, the master node is tainted with the \u201cNoSchedule\u201d effect by default so that no pod gets scheduled into it.

Visit here<\/a> for more information.<\/p>\n\n\n\n

Taint has three arguments<\/em> i.e. a key, value and effect.
Command for applying Taint to the node .<\/p>\n\n\n\n

kubectl taint node <Node_Name> <key=value:TAINT_EFFECT><\/code><\/pre>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Taint Effects<\/strong><\/h4>\n\n\n\n
There are three type\u2019s of taint effect which we can apply to a node and 
1- NoSchedule<\/strong>
     If we apply this taint effect to a node then it will only allow the pods which have a toleration effect equal to NoSchedule. But if a pod is already scheduled in a node and then you apply taint to the node having effect NoSchedule, then the pod will remain scheduled in the node.
<\/p>\n\n\n\n
2- PreferNoSchedule<\/strong>
      In this effect, it will first prefer for no scheduling of pod but if you have a single node and a PreferNoSchedule taint is applied on it. Then even if the pod didn’t tolerate the taint it will get schedule inside the node which has a taint effect: PreferNoSchedule.
<\/p>\n\n\n\n
3- NoExecute<\/strong><\/p>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
This effect will not only restrict the pod to get scheduled in the node but also if a pod is already scheduled a specific node and we have applied a taint of effect NoExecute to the specific node, it will immediately throw out the pod outside the node.
<\/p>\n\n\n\n
Pod Toleration<\/h3>\n\n\n\n
\"\"
Node Taint with Pod Toleration.<\/figcaption><\/figure>\n\n\n\n
As we know that node taints will repel a pod from scheduling in it. So, in order to prevent this, Kubernetes provides a concept of  pod toleration which gives pod an authority to get scheduled on the tainted node, if the toleration matches the node taint.  Tolerations are specified in PodSpec:<\/p>\n\n\n\n
apiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: noschedule-deployment\nspec:\n  replicas: 1\n  selector:\n    matchExpressions:\n    - key: name\n      operator: In\n      values:\n      - nginx\n  template:\n    metadata:\n      labels:\n        name: nginx\n    spec:\n      containers:\n      - name: nginx-container\n        image: nginx\n        ports:\n        - containerPort: 80\n      tolerations:\n      - key: size\n        operator: \"Equal\"\n        value: large\n        effect: NoSchedule<\/code><\/pre>\n\n\n\n
If you take a look at the above deployment you will see tolerations block inside podSpec  and inside that you will find some keywords like:
1 – key <\/strong>: The value which you have specified while applying node taint.
2 – value<\/strong> : Value that you have mentioned while applying the node taint.
3 – effect<\/strong> : Effect that you have mentioned while applying the node taint.
4 – Operator<\/strong> : There are 2 values of operator Equal and Exists.
         Equal: If we specify operator as Equal, then we have to specify all the key , value, and effect option.
         Exists: If we specify operator as Exists then it’s not compulsory to mention key, value, and effect option.<\/em><\/p>\n\n\n\n
If you want to allow your pod to tolerate every node taint then inside the pod toleration’s part, you should mention only the operator : \"Exists\"<\/code> .
By defining this your pod able will tolerate every taint which was applied on the node.<\/p>\n\n\n\n
\n