Skip to content
Latchkey

Kubernetes "node(s) didn't match node selector/affinity" in CI

The pod’s nodeSelector or nodeAffinity constrains it to nodes with specific labels, and no node in the cluster carries them. The scheduler has nowhere to put it, so it stays Pending.

What this error means

A pod is Pending with FailedScheduling: ... node(s) didn't match Pod's node affinity/selector. The constraint references a label (zone, instance type, custom pool) that no current node has.

kubectl describe pod
Warning  FailedScheduling  default-scheduler  0/5 nodes are available:
5 node(s) didn't match Pod's node affinity/selector.

Common causes

Label does not exist on any node

A nodeSelector like disktype: ssd or pool: gpu matches no node because the label was never applied or the node pool was removed.

Typo or wrong label key/value

A misspelled key, wrong case, or a value that does not match the node’s actual label leaves the selector unsatisfiable.

How to fix it

Compare the selector to node labels

Terminal
kubectl get pod <pod> -o jsonpath='{.spec.nodeSelector}'; echo
kubectl get nodes --show-labels

Fix the constraint or label the nodes

  1. Correct the selector/affinity key and value to match a real node label.
  2. Or label the intended nodes: kubectl label node <node> pool=gpu.
  3. For preferred (soft) placement, use preferredDuringScheduling so the pod still schedules if no node matches.

How to prevent it

  • Keep node labels and pod selectors in sync as node pools change.
  • Prefer soft affinity (preferred…) when placement is an optimization, not a hard requirement.
  • Validate selectors against kubectl get nodes --show-labels in CI.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →