Kubernetes nodeSelector and Taints: Pin a Workload to a Node Pool

Why you need both nodeSelector and a toleration

Taints and node selectors solve opposite halves of the same problem.

A taint on a node repels pods - dedicated=batch:NoSchedule means "nothing schedules here unless it explicitly opts in." It keeps general workloads off your batch pool. Without a taint, other pods will happily land on your dedicated hardware.

A nodeSelector attracts a pod to nodes that carry a matching label - workload: batch tells the scheduler "only place me on nodes with this label." Without the selector, your batch pod could land on any untainted node.

Together: the taint keeps the crowd out, the selector steers your pod in.

Label and taint the node pool

Before the Deployment can use them, the nodes need to be labeled and tainted:

kubectl label node <node-name> workload=batch
kubectl taint node <node-name> dedicated=batch:NoSchedule

In managed clusters (GKE, EKS, AKS) this is done through the node pool configuration - the same logic, just applied at provisioning time.

The Deployment manifest

Add nodeSelector and tolerations under spec.template.spec:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: batch
spec:
  replicas: 1
  selector:
    matchLabels:
      app: batch
  template:
    metadata:
      labels:
        app: batch
    spec:
      nodeSelector:
        workload: batch          # must match the node label
      tolerations:
      - key: dedicated
        operator: Equal
        value: batch
        effect: NoSchedule       # must match the taint effect
      containers:
      - name: batch
        image: busybox:1.36
        command: ["sleep", "86400"]

Apply it and confirm the fields landed in the live spec:

kubectl apply -f deployment.yaml
kubectl get deploy batch -o yaml | grep -A4 'nodeSelector\|tolerations'

Toleration fields explained

A toleration with operator: Exists and no key is a wildcard - it tolerates every taint on the node. Useful for DaemonSets, but too broad for workload pinning.

NoSchedule vs NoExecute

NoSchedule prevents new pods from landing but leaves existing pods running. NoExecute evicts pods that are already on the node and lack a matching toleration (add tolerationSeconds to delay eviction). Use NoSchedule for node pools; reserve NoExecute for drain-style operations.