Kubernetes Taints and Tolerations

Filed Under: Random
Taints & Tolerations

Hello, readers! In this article, we will be focusing on Kubernetes Taints and Tolerations in detail.

So, let us begin!! 馃檪


What is Kubernetes Taints and Tolerations?

In the series of Applying Pods to Nodes, we have already seen Kubernetes nodeSelector label and Affinity techniques.

Today, when it comes to scheduling Pods on specific nodes as well as restricting pods from specific nodes, Kubernetes has come up with Taints and Tolerations.

1. Taints

With Node Affinity, we tend to attract set of Pods to be scheduled onto the Nodes based on the labels. With Taints, we apply restrictions on the Node i.e. we let the node repel a certain set of pods based on the labels applied to the Node.

These Taints look for matching configurations within Pods. These configurations can be found as Tolerations.

2. Tolerations

Tolerations are the constraints that are applied on the Pod level. It enables the pods to be scheduled onto the Nodes that happen to have matching Taints.

With Taints, we tend to add labels on the Nodes and thus restrict the pods to bind to the Nodes based on the label values.

Tolerations and Taints go hand in hand, that is, Tolerations include the matching labels on the Pods with the Nodes (Taints). If the toleration does not find matching taint, it will not bind to the Node.

Let us have a look at the application of Taint and Tolerations in the upcoming sections.


Applying Taints & Tolerations on Kubernetes resources

We apply Taints on the nodes i.e. we apply labels on the nodes to restrict it from being available to all the Pods within the cluster.

Have a look at the below taint applied to the Node–

1. Taint on a Node

Here, we have applied taint to the node named node1 which has a key-value pair as demo-key:S1 and the effect as NoSchedule. Which means that no pod within the cluster will be able to bind to the node unless and until it has matching tolerations.

kubectl taint nodes node1 demo-key=S1:NoSchedule

At any point, if we wish to remove the taint applied on the Node, simply add a minus(-) sign ahead of the taint command as shown below–

kubectl taint nodes node1 demo-key=S1:NoSchedule-

2. Toleration on a Pod

Have a look at the below Toleration applied on a Pod–

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    env: QA
spec:
  containers:
  - name: nginx-init
    image: nginx
    imagePullPolicy: IfNotPresent
  tolerations:
  - key: "demo-key"
    operator: "Exists"
    value: "S1"
    effect: "NoSchedule"

The toleration includes the labels of the Taint i.e. the key, value and the effect of it. The operator Exists acts as a TRUE condition on the Toleration. As the toleration includes all the labels of the Taint, thus it can be bind with the Node node1.

3. The NoExecute effect on the Toleration

We can have multiple taints on a single node and multiple tolerations on the same pod. With NoExecute as a taint, if any pod does not have the configuration to tolerate the taint of the node, it evicts immediately. We can also have tolerationSeconds that specifies the time by which the pod can stay bound to the Node before eviction.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    env: QA
spec:
  containers:
  - name: nginx-init
    image: nginx
    imagePullPolicy: IfNotPresent
  tolerations:
- key: "demo-key"
  operator: "Equal"
  value: "S1"
  effect: "NoExecute"
  tolerationSeconds: 3600

In the above YAML, we have added the toleration of NoExecute effect to it. So, when a matching taint is added to it, the pod will be bound to the Node for 3600 seconds post which it would be evicted.


Conclusion

By this, we have come to the end of this topic. Feel free to comment below, in case you come across any question. For more such posts related to Kubernetes, Stay tuned with us.

Till then, Happy Learning! 馃檪

Leave a Reply

Your email address will not be published. Required fields are marked *

close
Generic selectors
Exact matches only
Search in title
Search in content