2.17 Kubernetes High Availability Architecture

Kubernetes High Availability Architecture is the specific arrangement of redundant control plane instances, load balancing, and leader election that allows a cluster to continue accepting requests and reconciling state even when individual control plane machines fail, distinguishing the differing replication strategies required for the API server, etcd, and singleton controllers respectively.

Redundancy Requirements Differ by Component

Not a Single Uniform Replication Strategy

High availability architecture in Kubernetes is built from three distinct replication strategies applied to three different kinds of components, rather than one uniform approach applied everywhere; the API server, etcd, and the scheduler and controller manager each require a different pattern because of how they differ in statefulness and concurrency safety.

API Server Replication Architecture

Stateless Replicas Behind a Load Balancer

Because the API server holds no state of its own beyond what it reads from and writes to etcd, its high availability architecture is straightforward: multiple identical replicas run simultaneously, fronted by a load balancer that can route a given request to any healthy instance without any coordination required between replicas.

etcd Replication Architecture

Consensus-Based, Quorum-Dependent Redundancy

etcd's high availability architecture is fundamentally different: because it is the authoritative store of cluster state, its replicas must agree with one another through a consensus protocol, requiring a quorum of members to acknowledge a write before it is considered committed, rather than simply routing requests to any available replica.

Odd-Numbered Membership as a Structural Requirement

This consensus-based architecture requires an odd number of etcd members, since only an odd count allows a clear majority to be determined even when some members are unreachable, a constraint that does not apply to the stateless API server replicas.

Singleton Controller Replication Architecture

Leader Election Instead of Simultaneous Activity

The scheduler and the controllers within the controller manager cannot simply run multiple simultaneously active replicas the way the API server can, since concurrent, uncoordinated reconciliation by multiple instances could produce conflicting actions; their high availability architecture instead uses leader election, keeping only one replica active while others stand by ready to take over if the leader fails.

Composing the Three Strategies Into One Cluster

Independent Failure Domains, Jointly Necessary

A cluster is architected to be truly highly available only when all three strategies are applied together: API server replicas alone do not help if etcd itself has no redundancy, and etcd redundancy alone does not help if the scheduler has no standby ready to take over leadership after a failure.

High Availability Composition Diagram