Kubernetes as a container orchestration system helps us in managing and automating our workloads by helping us scale our containerized applications. All these applications have specific purposes and requirements depending on the use case. In this scenario, it becomes important to be able to control where we'd want our pods to run.
In such cases, you could take a look at taints and tolerations in Kubernetes. A taint is simply a key1=value1:taint-effect pair that you'd apply to a node with the taint command. Here, the taint-effect is the particular effect that you'd want your taint to have.
Now, for a pod to match this taint, it'll need to have a toleration field in its specification with the following values
tolerations:
- key: key1
operator: Equal
value: value1
effect: taint-effect
Hence, only those pods which have the toleration with the same key1,value1 pair in its specification will be deployed on the tainted node.
Why use taints? Here are a few examples where this Kubernetes feature is useful:
Let's say you have clients or tenants to whom you'd like to provide exclusive pod access. Using taints, you can create isolation between groups of tenants by making sure that each tenant gets their own pods on their specific node hence ensuring multi-tenancy.
You might need backup pods to have traffic re-directed to them in case of some internal failure or have specialized pods for different environments like prod, dev and testing. In these scenarios, tainting nodes to run specialized pods offers a great advantage as you get to have pods with customized resources.
You might also need to scale certain pods separately. Let's take an everyday use case where we have a website and traffic to our site is increasing. To solve increasing traffic, what we can do is set aside nodes with higher resources and taint them so that pods with tolerations get deployed on them.
Now, along with the help of the Kubernetes Autoscaler, pods deployed on the tainted nodes get scaled automatically depending on the traffic and both customers and executives are happy.
The use cases covered here aim to cover a few general use cases that you may encounter in your daily scenarios. Of course, with the addition of more tools such as the Autoscaler, you get a truly customizable experience when it comes to deploying your containerized workloads.
Quick Note: Before we get to taints I need to tell you something about scheduling in Kubernetes. Usually, you define the spec for your deployment and send it over to Kubernetes for the pods to get deployed on the appropriate node. If for some reason your pod doesn't get deployed, it'll remain in a Pending state.
Now, let's take an analogy for explaining taints. Imagine you're at a big event. At this event, there are organizers who manage the event. They usually have a backstage which is reserved for staff and performers. All these people who are allowed to the backstage need to have a particular wristband to go in and hence you, an attendee will only be allowed if you have that wristband.
Thinking about this in Kubernetes terms, the organizers are the Kubernetes cluster who make sure that you an attendee (pod) can't get to the backstage (node with taint) unless you have a wristband (toleration).