What's the practical difference between node affinity and a plain node selector, given affinity seems strictly more powerful?

nodeSelector is simpler and sufficient for the common case of "this pod must land on a node with this one exact label" — its simplicity is itself a real advantage for readability and for teams that don't need affinity's extra expressiveness. Node affinity is necessary whenever you need OR logic across multiple label values, soft (non-mandatory) preferences, or NotIn/Exists-style expressions that nodeSelector's flat exact-match model can't express at all.

nodeSelector only supports exact-match AND logic across specified labels: nodeSelector: { disktype: ssd, zone: us-east-1a } requires a node to match every listed key-value pair exactly — there's no way to express "match disktype=ssd OR disktype=nvme," no way to express a soft preference, and no way to match on label existence without knowing the exact value in advance.

Node affinity's matchExpressions support operators nodeSelector simply doesn't have: In, NotIn, Exists, DoesNotExist, Gt, Lt — this covers cases like "any node with a zone label, regardless of value" (Exists), "any node not labeled deprecated" (DoesNotExist), or "zone is us-east-1a OR us-east-1b" (In with multiple values), none of which nodeSelector can express.

preferredDuringSchedulingIgnoredDuringExecution has no nodeSelector equivalent at all: nodeSelector is always a hard requirement — there's no soft-preference mode. If the goal is "prefer nodes with this label, but still schedule elsewhere if none are available," node affinity's preferred variant is the only way to express that; nodeSelector would need to be entirely absent to allow the fallback, losing the preference signal altogether.

nodeSelector's simplicity is a genuine, non-trivial advantage for the common case: for the frequent scenario of "this pod requires exactly this one label to be present with this one exact value," nodeSelector's flat syntax is more immediately readable in a manifest than the equivalent affinity YAML (which requires nesting through spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms[].matchExpressions[]) — for a team maintaining many manifests, this readability difference is a real, practical consideration, not just an aesthetic one.

They can be combined, and Kubernetes evaluates both if both are present: a pod spec with both nodeSelector and nodeAffinity must satisfy both — this is occasionally used deliberately (a simple, always-required base constraint via nodeSelector, plus a more nuanced preference via affinity), though it's also a common source of confusion if someone doesn't realize both are in effect simultaneously.

• nodeSelector only supports exact-match AND logic across labels — no OR logic, no soft preferences, no existence-only matching.
• Node affinity's matchExpressions operators (In, NotIn, Exists, DoesNotExist, Gt, Lt) cover cases nodeSelector structurally cannot express.
• Only node affinity supports soft, non-mandatory preferences (preferredDuringSchedulingIgnoredDuringExecution) — nodeSelector is always a hard requirement.
• nodeSelector's flat, simple syntax remains a genuine readability advantage for the common single-exact-label-match case.

• Kubernetes: Assign Pods to Nodes using Node Affinity