In this lesson, you will learn how to use Taints and Tolerations to prevent unauthorized pods from landing on specific nodes, ensuring your workloads stay exactly where you need them.
The Concept: Taints and Tolerations
Think of a Taint as a "Do Not Disturb" sign hanging on a door, and a Toleration as a "VIP pass" that allows a specific guest to enter despite the sign.
By default, Kubernetes pods can be scheduled on any node that has enough resources. Sometimes, you need to isolate specific nodes—for instance, if you have nodes with high-performance GPUs, you don't want general-purpose web servers accidentally consuming those resources. You place a Taint on the GPU node to "repel" all incoming pods. Only pods with a matching Toleration can ignore that sign and run on the node.
Applying a Taint
To set a node aside, you use the kubectl taint command. If we want to isolate a node for a "backend" team, we mark it like this:
kubectl taint nodes node-1 dedicated=backend:NoSchedule
This tells the cluster: "Do not schedule any pods here unless they specifically agree to handle this dedicated=backend taint."
Configuring the Toleration
If you have a pod that should run on that node, you must update its manifest to include the corresponding toleration:
apiVersion: v1
kind: Pod
metadata:
name: backend-pod
spec:
containers:
- name: app
image: my-backend-app
tolerations:
- key: "dedicated"
operator: "Equal"
value: "backend"
effect: "NoSchedule"
Without this block, the pod will be rejected by node-1. Note that taints and tolerations don’t force a pod onto a node; they simply block the pod from landing on a node that doesn't want it. If you need to force a pod to a specific node, you would combine this with the nodeSelector concepts we covered previously.
Key Takeaway: Taints repel pods from nodes, while tolerations allow specific pods to bypass those restrictions, enabling precise infrastructure isolation.