Kubernetes New Added 9 September 2026

Kubernetes: node(s) didn't match Pod's node affinity/selector

No node carries the labels the pod insists on, so the scheduler rejects every candidate. It turns up after an upgrade that replaced nodes with a different label set, and in multi zone clusters where a pod is pinned to the zone of a volume it can no longer be placed near.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix

# What the pod is asking for
kubectl get pod web-0 -o jsonpath='{.spec.nodeSelector}{"\n"}{.spec.affinity}{"\n"}'

# What the nodes actually offer
kubectl get nodes --show-labels
kubectl get nodes -L topology.kubernetes.io/zone,node.kubernetes.io/instance-type

# Label a node, or soften the rule from required to preferred
kubectl label node ip-10-0-1-5 workload=batch

# A bound volume pins the zone, so check the volume before the scheduler
kubectl get pv -o custom-columns=NAME:.metadata.name,CLAIM:.spec.claimRef.name,ZONE:.spec.nodeAffinity

# Autoscaler logs say why no group could satisfy the pod
kubectl -n kube-system logs -l app=cluster-autoscaler --tail=50

How to diagnose Kubernetes errors

Kubernetes errors are best read as a state machine that got stuck. Pending means the scheduler could not place the pod (resources, taints, or an unbound volume). ImagePullBackOff means kubelet could not fetch the image (name, credentials, or registry). CrashLoopBackOff means the container starts and exits, so the answer is in the container's own logs. OOMKilled means the kernel killed it for exceeding its memory limit. Each state points at a different subsystem, and kubectl describe almost always contains the exact reason in its events.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

Start with kubectl describe pod <name> and read the Events section at the bottom. It names the precise failure, including registry errors and scheduling constraints.
For CrashLoopBackOff, read the previous container's logs: kubectl logs <pod> --previous. The current container may not have produced output yet.
Check resource pressure with kubectl top pod and kubectl top node, and compare against the pod's requests and limits.
Test RBAC directly: kubectl auth can-i <verb> <resource> --as=system:serviceaccount:<ns>:<sa>. This answers permission questions definitively.
For networking, confirm the Service has endpoints (kubectl get endpoints) before suspecting DNS, Ingress or the CNI.

Tools worth reaching for

kubectl describe
kubectl logs --previous
kubectl auth can-i
kubectl top
kubectl events --sort-by=.lastTimestamp
k9s

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

kubernetes.io

Related Kubernetes errors

See all 34 Kubernetes errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.