Etcd Topology Patterns: Stacked vs. External

What is the difference between stacked and external etcd topologies?

When designing a Highly Available (HA) Kubernetes cluster, one of the most critical architectural decisions is how you deploy etcd. Because etcd is the consistent, highly-available key-value store used as the absolute "source of truth" and backing store for all cluster data, its availability dictates the availability of the entire cluster.

Kubernetes offers two primary topologies for an HA control plane: Stacked and External. The core difference between the two lies in whether the etcd database shares the same physical or virtual machines as the rest of the Kubernetes control plane components (API Server, Controller Manager, Scheduler).

Here is a deep dive into how both topologies work, along with the reasoning and real-world trade-offs for choosing each.

---

1. Stacked etcd Topology

In a stacked HA topology, the distributed data storage cluster provided by etcd is "stacked" directly on top of the nodes that run the control plane components. This is the default topology created when using standard cluster bootstrapping tools like kubeadm.

• How it works: Every control plane node runs an instance of the kube-apiserver, kube-scheduler, and kube-controller-manager alongside a local etcd member. In this architecture, the local etcd member is configured to communicate only with the kube-apiserver located on that exact same node.
• The Advantages (Why use it): The primary benefit of a stacked topology is simplicity and resource efficiency. It requires less infrastructure because the control plane and data store share the same compute resources. You only need a minimum of three machines to establish a fully functional HA cluster. It is also significantly easier to set up and manage for replication.
• The Trade-offs (Risks): The major operational drawback is the risk of "failed coupling." Because the control plane and etcd are tightly coupled on the same machine, if a single node fails, your cluster simultaneously loses an etcd member and a control plane instance. This compounds the blast radius of a single hardware failure and compromises cluster redundancy much faster than decoupled setups.

---

2. External etcd Topology

An external HA topology entirely decouples the distributed data storage from the control plane computations.

• How it works: Your control plane nodes run the kube-apiserver, kube-scheduler, and kube-controller-manager, but they do not host any database components. Instead, the etcd members run on their own separate, dedicated hosts. Unlike the stacked model, each external etcd host communicates with the kube-apiserver of every control plane node in the cluster.
• The Advantages (Why use it): This topology provides a superior high availability and fault-isolation posture. By decoupling the control plane from the etcd quorum, losing a control plane instance or an etcd member has significantly less impact. For example, if a control plane node crashes, your etcd cluster remains entirely untouched and maintains its full 3-node or 5-node quorum, preserving data redundancy.
• The Trade-offs (Risks): The primary disadvantage is cost and operational footprint. An external topology requires twice the number of hosts compared to the stacked approach. To build a resilient HA cluster using this method, you need a minimum of three dedicated control plane nodes plus three dedicated etcd nodes, totaling at least six machines. It also requires highly complex, additional x509 certificate management to secure the network traffic between the API servers and the external database.

---

Summary Matrix

Feature	Stacked Topology	External Topology
Component Location	Co-located on Control Plane nodes.	Isolated on dedicated hosts.
Minimum Node Count (HA)	3 Nodes total.	6 Nodes total (3 CP, 3 Etcd).
API Server Connection	API Server talks only to local etcd.	API Server talks to all etcd members.
Failure Radius	High (Node loss = CP + DB loss).	Low (Node loss isolated to CP or DB).
Ideal Use Case	Edge clusters, resource-constrained environments, standard deployments.	Large-scale, business-critical production environments needing absolute resilience.