New county workloads stay Pending with no nodeName and events do not show ordinary capacity or affinity fit failures. Which control-plane component failure best explains this?
Select an answer to reveal the explanation.
Short Explanation
Pending with no node name is the scheduler's empty desk—nobody is assigning seats. If capacity and affinity look fine, check that kube-scheduler itself is alive and holding leadership.
Full Explanation
Pods remain Pending with no nodeName when no scheduler binds them. If events do not show ordinary resource fit or affinity failures—and capacity looks fine—the most coherent control-plane explanation is that kube-scheduler is down, crash-looping, or not holding leader election, so nothing assigns seats for new county workloads. kube-proxy programs Service dataplane rules on nodes; its crash loops break Service traffic for pods that already run, but they do not leave brand-new pods Pending without a nodeName awaiting scheduling. CoreDNS resolves Service DNS for clients; the scheduler does not need to resolve node hostnames via CoreDNS before writing a binding. DNS down is the wrong component for Pending-without-nodeName. CSI controller health matters for volume provisioning and some attach paths; pods without volume needs (and even many with Bound volumes) are not universally blocked from scheduling solely because CSI is unhealthy—so “always blocks scheduling” is overstated and not the best fit here. Exam caveat: Also verify the scheduler’s leader-election lease in kube-system, RBAC, and that multiple scheduler profiles were not misconfigured—but “no nodeName + no fit failures” is the classic scheduler-absent signature. Operational check: Check kube-scheduler static pod or Deployment health, logs, and leader-election Lease; restore the component; watch a Pending pod gain nodeName and a Successful scheduling event once the civic scheduler is electing again.