Municipal workloads stay Pending with events citing insufficient CPU on every node, yet all nodes are Ready. What distinguishes this from a node-health outage?
Select an answer to reveal the explanation.
Short Explanation
Ready nodes with Pending pods is often a packing problem, not a corpse problem—everyone’s alive, there’s just no free CPU seats left.
Full Explanation
When municipal workloads stay Pending with events citing insufficient CPU on every node yet all nodes are Ready, that distinguishes capacity exhaustion from a node-health outage: nodes can be healthy while cluster capacity is exhausted relative to Pod requests, leaving Pods unschedulable. Ready nodes with Pending Pods is often a packing problem, not a corpse problem—everyone’s alive, but free CPU seats are gone.
Insufficient CPU Pending does not mean kubelet is stopped on all nodes (that would show NotReady). It does not mean the API server certificate expired. It does not mean the CoreDNS ConfigMap is empty.
Exam caveat: check requests versus allocatable, not merely limits. Also consider taints, affinity, and fragmented capacity where no single node fits the Pod even if aggregate CPU looks free.
Operational check: describe Pending Pods for insufficient CPU events, compare requests to kubectl describe node allocatable, scale nodes or reduce requests, and confirm scheduling resumes for the municipal workloads. 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.