Court-records operators find kube-scheduler is not scheduling after a network partition, and leader-election leases look stuck. What concept explains this failure mode?
Select an answer to reveal the explanation.
Short Explanation
HA control-plane pieces elect a captain. After a partition, if nobody can hold the lease cleanly, the scheduler sits idle—even though pods are waiting—until leadership is clear again.
Full Explanation
HA control-plane components such as kube-scheduler use leader election—typically Lease or legacy Endpoints objects—so only one active leader schedules pods. After a network partition, leases can appear stuck or no candidate can renew leadership cleanly, stalling scheduling for court-records workloads until election recovers even though workers otherwise look fine. That leader-election concept explains this failure mode. Schedulers in HA configurations do use leader election; claiming they never do is false and sends operators down the wrong path when partitions hit. Leader election is not limited to CoreDNS and can absolutely stall the scheduler when the lease cannot be held; narrowing the concept to DNS alone is incorrect. Network partitions do not automatically upgrade or schedule Pending pods without a scheduler leader; pods wait until a leader can bind them to nodes. Exam caveat: Inspect coordination.k8s.io Leases in kube-system, control-plane connectivity, and clock sync. Forcing lease deletion on a live city cluster can be risky if the partition is not understood—restore network first when possible. Operational check: Identify the scheduler lease holder, heal the partition, confirm a leader is elected in logs/lease, and watch Pending court pods receive a nodeName and Successful scheduling events.