A node selector constrains where a Kubernetes pod can run by matching labels on nodes. Use it when a workload needs a labeled characteristic, such as an SSD-equipped worker. The scheduler still checks whether the selected node has resources available. section 2.1.3 section 4.1
To schedule a pod on a labeled worker:
- Inspect node labels with `kubectl get no --show-labels`. If the required label is absent, add it with `kubectl label no kind-worker disktype=ssd`. section 4.1
- Generate a starting manifest with `kubectl run ssd-pod --image=nginx --dry-run=client -o yaml > ssd-pod.yaml`. Under `spec`, add `nodeSelector:` at the same indentation as `containers:`, with `disktype: ssd` beneath it. section 4.1
- Create the pod from the manifest, then run `kubectl get po -o wide`. Check the `NODE` column: the worked example shows `ssd-pod` running on `kind-worker`. section 2.1.3 section 4.1
Unlike `nodeName`, a node selector identifies nodes by label, so more than one node can match. A toleration permits scheduling onto a tainted node but does not select that node. Node affinity is another label-based option when a fallback placement is needed. section 4.1.1 section 9.3.3 section 2.1.3
