Taints and tolerations in Kubernetes - Commands & Configuration

Introduction

Sometimes you want to keep certain computers in your Kubernetes cluster reserved for special tasks. Taints and tolerations help you do this by marking those computers and allowing only certain tasks to run on them.

When you want to reserve some nodes for high-priority workloads only.

When you want to prevent regular tasks from running on nodes with limited resources.

When you want to isolate workloads that need special hardware like GPUs.

When you want to avoid running test workloads on production nodes.

When you want to control where certain pods can be scheduled in your cluster.

Config File - taint-node.yaml

taint-node.yaml

apiVersion: v1
kind: Node
metadata:
  name: example-node
spec:
  taints:
  - key: special
    value: reserved
    effect: NoSchedule

This file adds a taint to the node named example-node. The taint has a key special with value reserved and effect NoSchedule. This means no pod can run on this node unless it has a matching toleration.

Commands

This command adds a taint to the node named example-node. It marks the node so that pods without a matching toleration will not be scheduled on it.

Terminal

kubectl taint nodes example-node special=reserved:NoSchedule

Expected Output

node/example-node tainted

This command lists all nodes with their taints to verify that the taint was applied correctly.

Terminal

kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, taints: .spec.taints}'

Expected Output

{

  "name": "example-node",

  "taints": [

    {

      "key": "special",

      "value": "reserved",

      "effect": "NoSchedule"

    }

  ]

}

{

  "name": "other-node",

  "taints": null

}

→

-o json - Outputs node details in JSON format

This command creates a pod that has a toleration matching the taint on example-node, allowing it to be scheduled there.

Terminal

kubectl apply -f pod-with-toleration.yaml

Expected Output

pod/my-pod created

This command shows the pods and the nodes they are running on to confirm the pod was scheduled on the tainted node.

Terminal

kubectl get pods -o wide

Expected Output

NAME     READY   STATUS    RESTARTS   AGE   NODE          

my-pod   1/1     Running   0          1m    example-node

→

-o wide - Shows extra details including node name

Key Concept

If you remember nothing else from this pattern, remember: taints mark nodes to repel pods, and tolerations let pods ignore those marks to run there.

Common Mistakes

Adding a taint to a node but not adding a matching toleration to the pod.

The pod will not be scheduled on the tainted node and may stay pending.

Always add a toleration in the pod spec that matches the node's taint key, value, and effect.

Using the wrong effect type in the taint or toleration (e.g., NoExecute instead of NoSchedule).

The pod scheduling behavior will not be as expected; pods might be evicted or blocked incorrectly.

Use the correct effect type that matches your scheduling needs: NoSchedule to block scheduling, NoExecute to evict running pods.

Forgetting to remove a taint when it is no longer needed.

Nodes remain reserved unnecessarily, reducing cluster resource availability.

Remove taints with kubectl taint nodes example-node special- when reservation is no longer required.

Summary

Use 'kubectl taint nodes' to mark nodes with taints that repel pods without matching tolerations.

Add matching tolerations in pod specs to allow pods to run on tainted nodes.

Verify taints with 'kubectl get nodes' and pod scheduling with 'kubectl get pods -o wide'.