Court-records pods stay Pending because their nodeSelector requires a label the target nodes do not have. Nodes themselves are Ready. How should this be classified?
Select an answer to reveal the explanation.
Short Explanation
The nodes are fine; the pods are picky. Wrong or missing labels mean the scheduler finds zero matches and leaves them Pending.
Full Explanation
Court-records Pods that stay Pending because their nodeSelector requires a label the target nodes do not have—while nodes themselves are Ready—should be classified as a scheduling mismatch: selector or affinity rules match no Ready nodes. The nodes are fine; the Pods are picky. Wrong or missing labels mean the scheduler finds zero matches for those municipal workloads.
This is not node NotReady from kubelet certificate expiry. It is not PVC Pending from a missing StorageClass provisioner. It is not CoreDNS CrashLoopBackOff from a bad Corefile—unless separate symptoms show those faults.
Exam caveat: describe the Pending Pod for “didn’t match” events listing failed node selectors or affinity. Fix labels on nodes or relax the Pod’s selector; do not treat healthy Ready nodes as down.
Operational check: compare Pod nodeSelector to kubectl get nodes --show-labels, add the required labels or adjust the selector, and confirm court-records Pods schedule onto Ready nodes. Keep civic change tickets precise: record object names, namespaces, and before/after observations so the next on-call engineer can replay the fix without guesswork. Prefer reversible steps and verify Ready or Bound state before closing the incident.