> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Configuring High Availability > Guide to designing and configuring a highly available Kubernetes control plane, covering component behaviors, etcd topologies, load balancing, leader election, and production recommendations. This guide explains how to design a highly available (HA) Kubernetes control plane, why HA matters, and practical topology options for etcd. It keeps the original diagrams and examples while clarifying component behavior, failure scenarios, and recommended configurations for production clusters. Why HA matters * If the control plane (master) is lost, pods already running on worker nodes continue to serve traffic. However, cluster operations that require control-plane intervention—such as scheduling new pods, replacing failed replicas, or applying configuration changes—will fail until a control-plane component becomes available. * In production you should avoid single points of failure by making the control plane redundant. An HA control plane improves cluster availability for control operations, not only for running workloads. How HA works at a glance * Run the same control-plane components (kube-apiserver, kube-controller-manager, kube-scheduler, and etcd) on multiple master nodes. * Put a load balancer in front of the kube-apiserver instances so clients (kubectl, controllers, etc.) can reach any healthy API server. * Use leader election for components that must be single-active (controller-manager and scheduler) to prevent duplicate actions. * Deploy etcd either as stacked members on control-plane nodes or on a separate external etcd cluster depending on reliability and operational requirements. Control plane components and HA behavior | Component | Primary role | HA mode | Notes | | - | -: | - | - | | kube-apiserver | API endpoint for cluster state and control | Active/active | Stateles s—multiple instances can run concurrently behind a load balancer. API servers read/write state from etcd. | | kube-controller-manager | Runs controllers that reconcile cluster state | Active/standby (leader election) | Only the leader performs actions; standby instances wait to take over if leader fails. | | kube-scheduler | Assigns pods to nodes | Active/standby (leader election) | Uses the same leader-election mechanism as controller-manager to avoid duplicate scheduling. | | etcd | Distributed key-value store with cluster state | Distributed (Raft consensus) | Requires quorum for consistency. Deploy as stacked or external topology depending on operational needs. | kube-apiserver — active/active * The API server can scale horizontally because it is essentially stateless; cluster state is persisted in etcd. * Put a load balancer (for example [HAProxy](https://www.haproxy.org/), [NGINX](https://www.nginx.com/), or a cloud load-balancer) in front of API servers. Point clients’ kubeconfigs to the load balancer address so requests route to any healthy API server. The API server listens on port 6443 by default. Example kubeconfig cluster entry (points to the load balancer): ```yaml theme={null} clusters: - cluster: server: "https://load-balancer.example.com:6443" certificate-authority-data: "" name: kubernetes ``` Controller-manager and scheduler — active/standby (leader election) * Controllers and the scheduler must avoid performing duplicate work. They therefore use leader election: one instance is the active leader while others remain standby. If the leader fails, another instance takes over. * Leader election is enabled by default and is controlled by flags like `--leader-elect`, `--leader-elect-lease-duration`, `--leader-elect-renew-deadline`, and `--leader-elect-retry-period`. Example flags for kube-controller-manager: ```bash theme={null} kube-controller-manager --leader-elect=true \ --leader-elect-lease-duration=15s \ --leader-elect-renew-deadline=10s \ --leader-elect-retry-period=2s \ [other options] ``` The scheduler uses the same leader-election mechanism with identical flags. Leader election is typically implemented via Kubernetes API objects (leases) so that at any time only one instance is active. A stylized diagram of two mirrored control-plane nodes labeled "Active" and "Standby," each containing Controller-Manager, Scheduler, API Server, and etcd components. It illustrates a high-availability Kubernetes control plane setup. etcd topologies: stacked vs external etcd is the single source of truth for cluster state. Choosing the right etcd topology affects availability, operational complexity, and recovery procedures. Two common deployment patterns: | Topology | Description | Pros | Cons | | - | - | - | - | | Stacked control plane | etcd runs on each control-plane node (one member per master) | Easier to set up; fewer servers to manage | If a control-plane node fails, you lose both the control plane components and that etcd member — can reduce quorum and availability | | External etcd | etcd runs on separate dedicated nodes (independent from masters) | Greater isolation and resilience: control-plane failure doesn't remove an etcd member | More servers and more operational complexity to manage | 1. Stacked control plane topology (etcd on each control plane node) * Each master hosts an etcd member alongside kube-apiserver, kube-controller-manager, and kube-scheduler. * Simpler deployment footprint and fewer machines to manage, but a failed master removes an etcd member which may reduce cluster quorum, depending on cluster size. A slide titled "Stacked Topology" showing two master-node diagrams, each containing etcd, API Server, Controller-Manager, and Scheduler components. A bullet list at right notes pros (easier to set up/manage, fewer servers) and a con (risk during failures). 2. External etcd topology (separate etcd cluster) * etcd runs on dedicated servers separate from control-plane nodes. * This reduces coupling: a control-plane node failure does not remove etcd members and does not directly affect etcd quorum. * Requires more servers and a separate operational procedure for etcd backups, restores, and scaling. etcd configuration and API server integration * The kube-apiserver is the only control-plane component that communicates directly with etcd. Provide it with the list of etcd server endpoints via the `--etcd-servers` flag. Example kube-apiserver flag: ```bash theme={null} kube-apiserver --etcd-servers="https://etcd1.example.com:2379,https://etcd2.example.com:2379,https://etcd3.example.com:2379" \ [other options] ``` * etcd uses Raft consensus. Clients may read from and write to any member, but quorum (majority) is required for commits. For production clusters, use an odd number of etcd members (typically 3 or 5) to tolerate failures while minimizing split-brain risk. For production etcd clusters, follow quorum best practices: use an odd number of members (3 or 5 typically) to tolerate failures while minimizing split-brain risk. Also implement regular backups and test restores as part of your operational runbook. Putting the pieces together: converting a single-master cluster to HA * Add additional master nodes that run the same control-plane components. * Deploy a load balancer in front of kube-apiserver instances and update kubeconfigs to point at the load balancer. * Ensure controller-manager and scheduler are configured for leader election (default behavior). * Choose an etcd topology (stacked or external) based on your reliability goals and available infrastructure: * Stacked: fewer machines, simpler setup, but consider quorum impact when masters fail. * External: better isolation, more resilient etcd cluster, but more machines and operational complexity. * Monitor control-plane components, etcd quorum status, and load-balancer health. Test failover scenarios and restore procedures before promoting the cluster to production. Further reading and references * [Kubernetes control plane components](https://kubernetes.io/docs/concepts/overview/components/) * [etcd documentation](https://etcd.io/docs/) * [Kubernetes high-availability considerations](https://kubernetes.io/docs/setup/production-environment/tools/) This enhanced explanation preserves the original diagrams and examples while clarifying behaviors and configuration options for an HA Kubernetes control plane. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.