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.

Practice

1. What is the main purpose of a taint in Kubernetes?

easy

A. To repel pods from nodes unless they have matching tolerations

B. To allow pods to run on any node without restrictions

C. To label pods for easier identification

D. To increase node resource limits automatically

Solution

1. Step 1: Understand what a taint does

   A taint is applied to a node to repel pods that do not tolerate it.

2. Step 2: Compare with other options

   Options B, C, and D describe unrelated features: pod scheduling without restrictions, pod labeling, and resource limits, which are not taint functions.

3. Final Answer:

   To repel pods from nodes unless they have matching tolerations -> Option A

4. Quick Check:

   Taints repel pods without tolerations = A [OK]

Hint: Taints push pods away; tolerations allow pods to stay [OK]

Common Mistakes:

• Confusing taints with labels
• Thinking taints increase resources
• Assuming taints allow all pods

2. Which of the following is the correct syntax to add a taint to a node named node1 that repels pods without the matching toleration?

easy

A. kubectl taint nodes node1 key=value:NoSchedule

B. kubectl label nodes node1 key=value:NoSchedule

C. kubectl taint pods node1 key=value:NoSchedule

D. kubectl tolerate nodes node1 key=value:NoSchedule

Solution

1. Step 1: Identify the correct command for tainting nodes

   The command to add a taint is kubectl taint nodes followed by node name and taint details.

2. Step 2: Check the options

   kubectl taint nodes node1 key=value:NoSchedule uses the correct syntax. kubectl label nodes node1 key=value:NoSchedule uses label instead of taint. kubectl taint pods node1 key=value:NoSchedule tries to taint pods, which is invalid. kubectl tolerate nodes node1 key=value:NoSchedule uses a non-existent command.

3. Final Answer:

   kubectl taint nodes node1 key=value:NoSchedule -> Option A

4. Quick Check:

   Use kubectl taint nodes for taints = A [OK]

Hint: Use 'kubectl taint nodes' to add taints, not labels or pods [OK]

Common Mistakes:

• Using 'label' instead of 'taint'
• Trying to taint pods instead of nodes
• Using wrong command like 'tolerate'

3. Given the following pod spec snippet, what will happen if the node has the taint key=value:NoSchedule?

tolerations:
- key: "key"
  operator: "Equal"
  value: "value"
  effect: "NoSchedule"

medium

A. The pod will be scheduled but evicted immediately

B. The pod will be scheduled on the tainted node

C. The pod will be rejected and not scheduled

D. The pod will ignore the taint and schedule anywhere

Solution

1. Step 1: Understand the pod toleration

   The pod tolerates the taint with matching key, value, and effect, so it can be scheduled on the node.

2. Step 2: Analyze the taint effect

   The taint effect is NoSchedule, which prevents pods without tolerations from scheduling. Since this pod has the matching toleration, it is allowed.

3. Final Answer:

   The pod will be scheduled on the tainted node -> Option B

4. Quick Check:

   Matching toleration allows scheduling despite taint = C [OK]

Hint: Matching toleration lets pod schedule on tainted node [OK]

Common Mistakes:

• Ignoring the value match in toleration
• Confusing NoSchedule with NoExecute
• Assuming tolerations always allow scheduling

4. You applied the taint key=value:NoSchedule to a node, but pods without tolerations are still scheduling on it. What is the most likely cause?

medium

A. Pods have tolerations matching the taint

B. Taints do not affect scheduling

C. The node is in a NotReady state

D. The taint was applied with a typo in the key or value

Solution

1. Step 1: Check taint correctness

   If pods without tolerations schedule on a tainted node, the taint might have a typo or was not applied correctly.

2. Step 2: Evaluate other options

   Pods have tolerations matching the taint means pods tolerate the taint, which contradicts the question. The node is in a NotReady state is unrelated to taints. Taints do not affect scheduling is false because taints do affect scheduling.

3. Final Answer:

   The taint was applied with a typo in the key or value -> Option D

4. Quick Check:

   Incorrect taint syntax causes scheduling errors = B [OK]

Hint: Check taint spelling carefully if pods ignore it [OK]

Common Mistakes:

• Assuming taints don't affect scheduling
• Ignoring typos in taint keys or values
• Confusing node status with taint issues

5. You want to ensure that only pods with a specific toleration can run on a node, and all other pods are evicted if already running. Which taint effect should you use?

hard

A. NoSchedule

B. PreferNoSchedule

C. NoExecute

D. NoEvict

Solution

1. Step 1: Understand taint effects

   NoSchedule prevents new pods without tolerations from scheduling. PreferNoSchedule tries to avoid scheduling but doesn't guarantee. NoExecute evicts existing pods without tolerations and prevents new ones. NoEvict is not a valid effect.

2. Step 2: Match requirement to effect

   Since you want to evict existing pods without tolerations, NoExecute is the correct effect.

3. Final Answer:

   NoExecute -> Option C

4. Quick Check:

   Evict pods without tolerations = NoExecute = D [OK]

Hint: Use NoExecute to evict pods lacking tolerations [OK]

Common Mistakes:

• Choosing NoSchedule which doesn't evict existing pods
• Confusing PreferNoSchedule with eviction
• Using invalid effect NoEvict