Describe your nodes and paste a pod, and see which nodes it can land on and why the rest cannot. Required rules exclude and preferred rules only score, which is the distinction that leaves a pod Pending or in the wrong zone.
One node per line: name: key=value,key=value. kubectl get nodes --show-labels gives you these.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Test. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
Required affinity naming a zone no node has, which is Pending with no obvious cause
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: zone
operator: In
values: [eu-west-1c]A preference that does not block scheduling, only influences it
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
preference:
matchExpressions:
- key: type
operator: In
values: [on-demand]These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
requiredDuringScheduling means the pod stays Pending forever if nothing matches. There is no fallback.
Instead:Use preferred unless the pod genuinely cannot run elsewhere.
IgnoredDuringExecution means a running pod stays put even when the node stops matching.
Instead:Nothing re-evaluates. Evict deliberately if placement must change.
nodeSelector is exact-match only and cannot express In, NotIn or Exists.
Instead:Use nodeAffinity for anything beyond equality.
A required rule that matches nothing leaves the pod Pending forever with no error at apply time. A preferred rule that matches nothing changes nothing at all and the pod schedules anywhere. Both look almost identical in YAML.
nodeSelectorTerms is a list and a node qualifies if it satisfies ANY term. Inside one term, every matchExpression must hold. This reads backwards from most selector syntax, where a list of conditions is usually ANDed, and it is why splitting two conditions into two terms quietly widens a rule instead of narrowing it.
A nodeSelector cannot express In, NotIn or Exists: it is a flat map compared for equality. When both a nodeSelector and node affinity are present, a node has to satisfy both. Gt and Lt exist in node affinity and nowhere else, and they compare integers, so a label whose value is not an integer never matches them.
Taints, which are a separate mechanism and exclude pods that these rules would allow: the taint and toleration tester on this site covers those. Resource requests, so a node that qualifies here may still have no room. And pod affinity, which depends on what is already running rather than on labels.