In OpenShift (OCP) and Kubernetes, a taint is a core scheduling mechanism applied to a node that allows the node to repel pods.

Think of a taint as a “Keep Out” sign placed on a server.By default, the OpenShift scheduler will not place any application pod on a tainted node unless that pod explicitly carries a matching toleration (a “key pass”).

While Node Selectors and Node Affinity are used to attract pods to specific nodes, Taints and Tolerations are used to repel unwanted pods away from nodes.

1. Anatomy of a Taint

A taint consists of three components: a Key, an optional Value, and a Taint Effect:

Taint} = key=value:Effect

The Three Taint Effects:

• NoSchedule (Hard Restriction):New pods without a matching toleration will never be scheduled onto this node.However, any pods already running on the node before the taint was applied are left alone.
• PreferNoSchedule (Soft Restriction):The scheduler tries to avoid placing pods on this node, but if no other compute resources are available in the cluster, it will place the pod here anyway.
• NoExecute (Eviction Restriction):The strongest effect.Any pod currently running on the node that does not tolerate the taint is immediately evicted (killed and rescheduled elsewhere).

2. Common Real-World Use Cases in OpenShift

• Dedicated Infrastructure Nodes:Isolating OpenShift Infra components (Ingress Routers, Monitoring, Image Registry) onto dedicated worker nodes so user applications cannot drain their resources.
• Specialized Hardware (GPUs / High-RAM):Tainting nodes that have expensive NVIDIA GPUs (gpu=true:NoSchedule) so standard web apps don’t accidentally get scheduled on them, reserving the hardware strictly for AI/ML workloads.
• Master Node Isolation:OpenShift automatically places a taint on Control Plane (master) nodes (node-role.kubernetes.io/master=:NoSchedule) so user workloads only run on worker nodes.
• Node Maintenance / Failure (Taint-based Eviction):When a node loses network connection or runs out of disk, OpenShift automatically applies temporary system taints like node.kubernetes.io/unreachable:NoExecute or node.kubernetes.io/disk-pressure:NoSchedule.

3. Declarative Setup Example

Step A: Applying a Taint to an OCP Node

Using the CLI, an administrator marks a node designated for GPU processing:

oc adm taint nodes worker-gpu-0 gpu=nvidia:NoSchedule

Step B: Adding a Toleration to a Pod Deployment

To allow a machine learning pod to run on that node, you add a tolerations block to its PodSpec:

YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ml-model-trainer
spec:
  template:
    spec:
      containers:
        - name: cuda-runner
          image: quay.io/ai-lab/cuda-runner:latest
      # The Pod MUST have this matching toleration to land on worker-gpu-0
      tolerations:
        - key: "gpu"
          operator: "Equal"
          value: "nvidia"
          effect: "NoSchedule"

Note: A toleration allows a pod to run on a tainted node, but it does not force it to go there.If you want to force the pod onto that specific GPU node, combine the Toleration with a nodeSelector or NodeAffinity.