3.14 Kubernetes Control Plane Leader Election
Kubernetes Control Plane Leader Election ensures a single active control plane component to manage cluster operations through a distributed coordination mechanism.
Kubernetes Control Plane Leader Election is the specific mechanism by which multiple replicas of the scheduler or a controller manager agree on exactly one active instance, describing how this agreement is achieved through a shared lease object stored in the API server rather than through direct communication between the competing replicas themselves.
A Lease as the Coordination Point
Replicas Compete for a Shared Object
Leader election is architected around a single lease object, stored as an ordinary API resource, which every replica of a given component attempts to acquire or renew; the replica currently holding the lease is the active leader, and every other replica remains a passive standby.
No Direct Communication Between Replicas
Because coordination happens entirely through this shared lease object read from and written to the API server, replicas never need to communicate with each other directly, consistent with the broader hub-and-spoke communication pattern used throughout the control plane.
Acquiring and Renewing Leadership
Initial Acquisition When No Leader Exists
When no valid lease currently exists, or an existing lease has expired without being renewed, any competing replica may attempt to acquire it by writing itself as the holder, with the API server's own concurrency controls ensuring only one such attempt can succeed if multiple replicas try simultaneously.
Periodic Renewal to Retain Leadership
Once acquired, the current leader is architected to renew its lease periodically, well before its expiration time, signaling to standby replicas that it remains active and that they should continue waiting rather than attempting to take over.
Failover When a Leader Disappears
Expiration as the Failure Signal
If the current leader fails to renew its lease before it expires, whether due to a crash, network partition, or simple unresponsiveness, the lease becomes available, and standby replicas begin competing to acquire it, with one of them becoming the new leader.
Bounded, Not Instantaneous, Failover Time
Because failover depends on the lease's expiration timeout elapsing, this mechanism is architected to have a bounded but non-zero gap in active leadership following a failure, rather than an instantaneous handoff, a tradeoff accepted in exchange for the simplicity of coordinating purely through a shared object.
Why This Matters for Correctness
Preventing Conflicting Concurrent Reconciliation
Leader election exists specifically to prevent the scenario where two replicas of the same controller simultaneously believe they are responsible for reconciling the same resources, which could otherwise result in duplicated or conflicting actions being taken against the cluster.