🧠 Kubernetes Scheduling Control: Taints, Tolerations, Node Selectors, and Node Affinity¶

A complete intellectual journey from why to how, exploring how Kubernetes gives you control over where Pods run, using taints, tolerations, selectors, and affinities.

🧩 PROBLEM STATEMENT #1 — Unwanted Pods Are Scheduled on Certain Nodes¶

Imagine you have a special node meant only for specific workloads — high CPU, sensitive data, or GPU jobs. But Kubernetes, by default, sees every node as equal and might schedule general-purpose Pods there too.

🔧 SOLUTION — Taint the Node & Add Tolerate in Pod¶

A taint repels all Pods unless those Pods have a matching toleration.

Taint = Applied to the node (it repels Pods)

Toleration = Applied to the Pod (it tolerates the taint)

🧪 Real-Life Analogy¶

A tainted node is like a VIP lounge — only those with a matching wristband (toleration) can enter. Others are not allowed in.

🔨 Imperative Command¶

kubectl taint node ibtisam-worker flower=rose:NoSchedule
kubectl describe node ibtisam-worker | grep -i taint -A 5
kubectl taint node ibtisam-worker flower=rose:NoSchedule-

The - at the end removes the taint.

🌱 Example Manifest (Tolerating a Taint)¶

apiVersion: v1
kind: Pod
metadata:
  name: tol-po
spec:
  containers:
  - name: abcd
    image: busybox
    command: ["sleep", "3600"]
  tolerations:
  - key: "flower"
    operator: "Equal"
    value: "rose"
    effect: "NoSchedule"

🎯 Effects of Taint¶

⚠️ PROBLEM #2 — Even Tolerated Pods May Go to the Wrong Node¶

Even after a Pod tolerates a taint, Kubernetes might still schedule it on any other untainted node.

You want a Pod to go to a specific node — but toleration alone doesn't guarantee where it goes, just that it can go.

🧠 SOLUTION — Add a Node Label & Use nodeName, nodeSelector or affinity¶

kubectl label node ibtisam-worker cpu=large
kubectl label node ibtisam-worker cpu- # remove the label

Example: Node Name¶

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
  nodeName: kube-01

The above Pod will only run on the node kube-01.

🌱 Example: Node Selector¶

apiVersion: v1
kind: Pod
metadata:
  name: nodeselector-po
spec:
  containers:
  - name: abcd
    image: busybox
    command: ["sleep", "3600"]
  nodeSelector:
    cpu: large

⚠️ Limitation of Node Selector¶

• Only supports = operator
• No fallback or flexible logic
• Can only match one label

This is where Node Affinity enters the picture

🔁 Node Affinity — Flexible and Declarative¶

nodeAffinity gives you expressive control over scheduling using multiple operators and terms.

🧩 Syntax Inside Pod Spec¶

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:  # Hard rule
      preferredDuringSchedulingIgnoredDuringExecution: # Soft rule

🧪 Real-Life Analogy¶

It’s like saying: "I require a hotel with Wi-Fi (hard rule), but prefer one with a pool too (soft rule)."

💎 Node Affinity Types Explained¶

1. requiredDuringSchedulingIgnoredDuringExecution (Hard)¶

Pod must be scheduled on a matching node or stay pending.

apiVersion: v1
kind: Pod
metadata:
  name: ha-po
spec:
  containers:
  - name: abcd
    image: busybox
    command: ["sleep", "3600"]
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd
            - hdd

2. preferredDuringSchedulingIgnoredDuringExecution (Soft)¶

Kubernetes will try to match, but falls back if needed.

apiVersion: v1
kind: Pod
metadata:
  name: sa-po
spec:
  containers:
  - name: abcd
    image: busybox
    command: ["sleep", "3600"]
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd
            - hdd

3. requiredDuringSchedulingRequiredDuringExecution¶

(Proposed feature) Enforces node match even after scheduling.

⚙️ Operators in Node Affinity¶

🔁 Combined Example — Toleration + Node Affinity¶

apiVersion: v1
kind: Pod
metadata:
  name: tol-ha-po
spec:
  containers:
  - name: abcd
    image: busybox
    command: ["sleep", "3600"]
  tolerations:
  - key: "flower"
    operator: "Equal"
    value: "rose"
    effect: "NoSchedule"
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd
            - hdd

By-default Taint on Control Plane Nodes¶

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

kubectl get nodes --show-labels
NAME           STATUS   ROLES           AGE   VERSION   LABELS
controlplane   Ready    control-plane   10m   v1.32.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=controlplane,kubernetes.io/os=linux,node-role.kubernetes.io/control-plane=,node.kubernetes.io/exclude-from-external-load-balancers=

node01         Ready    <none>          10m   v1.32.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node01,kubernetes.io/os=linux

¶

📌 Final Thoughts — When to Use What?¶

🧵 Conclusion: How Everything Connects¶

Together, taints + tolerations repel and allow selectively, while labels + nodeSelector/affinity attract and guide where pods land.

✅ Use taints when you want to protect a node from unwanted workloads. ✅ Use tolerations when you want specific pods to enter protected nodes. ✅ Use nodeSelector/affinity when you want specific pods to land on specific nodes.

That's how you gain full control over pod placement in your cluster — like an air traffic controller for your workloads. ✈️

Want to learn more? 🤔¶

Please click here for understanding this topic in more depth.