Taints and tolerations in Kubernetes - Step-by-Step Execution

Process Flow - Taints and tolerations

Add Taint to Node

↓

Pod Scheduled?

↓

Pod Allowed

This flow shows how a node with a taint affects pod scheduling. Pods must have matching tolerations to be allowed on tainted nodes.

Execution Sample

Kubernetes

kubectl taint nodes node1 key=value:NoSchedule
kubectl apply -f pod.yaml
# pod.yaml has tolerations for key=value
kubectl get pods
kubectl describe pod pod1

This sequence adds a taint to a node, applies a pod with matching tolerations, then checks pod status and details.

Process Table

Step	Action	Node State	Pod Tolerations	Scheduling Result	Notes
1	Add taint key=value:NoSchedule to node1	node1 tainted with key=value:NoSchedule	N/A	N/A	Node now rejects pods without matching toleration
2	Apply pod1 with toleration key=value:NoSchedule	node1 tainted	tolerates key=value:NoSchedule	Pod scheduled	Pod allowed on tainted node due to toleration
3	Apply pod2 without tolerations	node1 tainted	no tolerations	Pod pending	Pod rejected by scheduler due to taint
4	Describe pod1	node1 tainted	tolerates key=value:NoSchedule	Running	Pod is running on tainted node
5	Describe pod2	node1 tainted	no tolerations	Pending	Pod waiting for suitable node
6	Remove taint from node1	node1 no taints	N/A	N/A	Node accepts all pods now
7	Pod2 scheduled after taint removal	node1 no taints	no tolerations	Pod scheduled	Pod2 now runs on node

💡 Pods without matching tolerations cannot schedule on tainted nodes; removing taint allows scheduling.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 6	Final
node1_taints	none	key=value:NoSchedule	key=value:NoSchedule	key=value:NoSchedule	none	none
pod1_tolerations	none	none	key=value:NoSchedule	key=value:NoSchedule	key=value:NoSchedule	key=value:NoSchedule
pod2_tolerations	none	none	none	none	none	none
pod1_status	N/A	N/A	Scheduled	Scheduled	Scheduled	Running
pod2_status	N/A	N/A	Pending	Pending	Scheduled	Running

Key Moments - 3 Insights

Why does pod2 stay pending even though node1 exists?

Because node1 has a taint key=value:NoSchedule and pod2 does not have a matching toleration, so the scheduler blocks pod2 from running on node1 (see execution_table step 3).

What allows pod1 to run on the tainted node?

Pod1 has a toleration matching the node's taint key=value:NoSchedule, so the scheduler permits it to run on node1 despite the taint (see execution_table step 2).

What happens when the taint is removed from node1?

All pods, including those without tolerations like pod2, can schedule on node1 because the taint no longer blocks them (see execution_table steps 6 and 7).

Visual Quiz - 3 Questions

Look at the execution table at step 3. What is the scheduling result for pod2?

A Pod running

B Pod scheduled

C Pod pending

D Pod deleted

💡 Hint

Check the 'Scheduling Result' column for step 3 in the execution_table.

At which step is the taint removed from node1?

A Step 2

B Step 6

C Step 4

D Step 7

💡 Hint

Look for the action mentioning 'Remove taint' in the execution_table.

If pod1 did not have the toleration, what would happen at step 2?

A Pod1 would be pending

B Pod1 would be scheduled

C Pod1 would be deleted

D Pod1 would run on another node

💡 Hint

Refer to the logic in concept_flow and the scheduling results for pods without tolerations.

Concept Snapshot

Taints mark nodes to repel pods.
Pods must have matching tolerations to run on tainted nodes.
Taint format: key=value:effect (e.g., NoSchedule).
Tolerations in pod spec allow ignoring taints.
Without toleration, pods stay pending on tainted nodes.
Removing taint allows all pods to schedule.

Full Transcript

Taints and tolerations control pod scheduling on Kubernetes nodes. When a node is tainted, it repels pods unless they have a matching toleration. The flow starts by adding a taint to a node. Then, when pods are scheduled, the scheduler checks if the pod tolerates the node's taint. If yes, the pod runs on the node; if not, the pod remains pending. Removing the taint allows all pods to schedule on the node. This mechanism helps control workload placement by marking nodes with special conditions and letting only certain pods run there.