Cloud Native 17 min read

Master Kubernetes Taints and Tolerations: A Complete Guide to Node Isolation and Scheduling

This article provides a comprehensive overview of Kubernetes taints and tolerations, explaining their structure, default cluster taints, management commands, and how different taint effects (PreferNoSchedule, NoSchedule, NoExecute) influence pod scheduling, along with detailed examples of toleration configurations.

Ops Community
Ops Community
Ops Community
Master Kubernetes Taints and Tolerations: A Complete Guide to Node Isolation and Scheduling

Overview

Kubernetes taints are node-level attributes that repel pods unless the pods explicitly tolerate them, enabling fine‑grained control over pod placement and eviction.

Taint Structure

A taint follows the syntax

key=value:effect

, where

key

is a custom identifier,

value

is optional, and

effect

can be PreferNoSchedule , NoSchedule , or NoExecute .

Purpose of Taints

Isolate nodes for special workloads (e.g., GPU or high‑memory nodes).

Evict pods that do not tolerate a taint during node maintenance.

Implement hierarchical scheduling strategies to separate environments such as dev, test, and prod.

Default Taints in a Cluster

node-role.kubernetes.io/control-plane:NoSchedule

node.kubernetes.io/not-ready:NoExecute

node.kubernetes.io/unreachable:NoExecute

node.kubernetes.io/out-of-disk:NoExecute

node.kubernetes.io/memory-pressure:NoExecute

node.kubernetes.io/disk-pressure:NoExecute

node.kubernetes.io/pid-pressure:NoExecute

Managing Taints

View Taints

<code># kubectl describe node | grep Taints</code>

Add Taint

<code># kubectl taint node <node-name> key[=value]:effect</code>

Remove Taint

<code># kubectl taint node <node-name> key:effect-</code>

Modify Taint

Modifying a taint is performed by removing the existing taint and then adding a new one.

Testing Taint Effects

PreferNoSchedule

Pods will try to avoid the tainted node; if no other node is suitable, they may still be scheduled there.

NoSchedule

Pods are prohibited from being scheduled onto the node unless they have a matching toleration.

NoExecute

Pods are prohibited from being scheduled and existing pods without a matching toleration are evicted.

Tolerations

Pods declare tolerations in

spec.tolerations

to match node taints. Matching rules include:

Exact

key

+

operator

+

value

+

effect

match.

operator: Exists

matches any taint with the given key, regardless of value or effect.

Omitting

key

and

operator

matches all taints (use with caution).

Example Toleration

<code>tolerations:
- key: "app"
  operator: "Equal"
  value: "web"
  effect: "NoSchedule"
</code>
Kubernetesschedulingnodetainttoleration
Ops Community
Written by

Ops Community

A leading IT operations community where professionals share and grow together.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.