3.15 Kubernetes Control Plane High Availability
Ensuring Kubernetes control plane high availability through redundancy, fault tolerance, and distributed architecture across multiple nodes.
Kubernetes Control Plane High Availability is the specific set of failure scenarios a replicated control plane is designed to survive, describing what actually happens to cluster behavior at the moment a control plane member fails, rather than the replication strategies themselves, which govern how that survival is achieved.
Failure of a Single API Server Replica
Load Balancer Reroutes Without Client Awareness
When one API server replica becomes unavailable, the load balancer in front of the replica set is architected to stop routing traffic to it and continue directing requests to the remaining healthy replicas, meaning clients experience no interruption beyond, at most, the brief window before the unhealthy replica is detected and removed from rotation.
No Loss of In-Flight State
Because API server replicas are stateless with respect to each other, losing one does not lose any data; every replica reads from and writes to the same etcd cluster, so the failed replica's absence has no bearing on what state remains available.
Failure of a Single etcd Member
Cluster Continues Operating Below Full Membership
When one etcd member fails, the remaining members continue operating normally so long as a quorum, a majority of the total membership, is still reachable; reads and writes continue to succeed, though the cluster is now more vulnerable to a second failure since one fewer member remains to help form future quorums.
Loss of Quorum Halts Writes Entirely
If enough etcd members fail simultaneously that a quorum can no longer be formed, the etcd cluster stops accepting writes altogether, which in turn halts the API server's ability to persist any new state, effectively freezing the cluster's ability to accept changes until quorum is restored.
Failure of the Active Scheduler or Controller Manager Leader
Standby Takes Over After Lease Expiration
When the currently active scheduler or controller manager replica fails, its leadership lease eventually expires without renewal, at which point a standby replica acquires the lease and becomes the new active instance, resuming reconciliation or scheduling from the cluster's current, unaffected state.
A Bounded Gap in Active Reconciliation
During the period between the failure and the new leader taking over, no scheduling or reconciliation for that component's responsibilities occurs, meaning already-running workloads continue functioning normally, but newly created Pods may sit unscheduled and drifted state may go temporarily uncorrected until failover completes.
Composite Failures
Multiple Simultaneous Failures Stress the Weakest Link
A cluster's overall high availability in the face of multiple simultaneous failures is bounded by whichever component's redundancy is exhausted first, most often etcd, since its quorum requirement is stricter than the simple majority-of-one needed by stateless API server replicas.