How does etcd's quorum requirement affect control-plane node count, and why is an even number a bad choice?

etcd requires a strict majority (quorum) of its members to be available and agreeing for the cluster to accept writes — for N members, quorum is floor(N/2) + 1. This means 4 members tolerate the loss of only 1 node (same as 3 members), while 5 members tolerate the loss of 2 — an even-numbered cluster gets no additional fault tolerance over the next-lower odd number, while still paying the cost of an extra node, making even numbers strictly worse value than the nearest lower odd number.

Quorum is a majority, and majority math doesn't reward even numbers: for 3 members, quorum is 2 — the cluster tolerates 1 failure (2 remaining still form a majority). For 4 members, quorum is 3 — the cluster still only tolerates 1 failure (losing 2 of 4 leaves exactly 2, which is not a majority of 4), meaning the 4th node added no fault tolerance at all over 3, just extra infrastructure and an extra vote in every consensus round.

5 members genuinely improve on 3 — this is where added nodes actually pay off: quorum for 5 is 3, and the cluster tolerates 2 failures (3 remaining is still a majority) — this is a real, meaningful improvement over 3 members' single-failure tolerance, unlike the 3-to-4 jump which added cost without added tolerance.

The general pattern: going from an odd number N to N+1 (making it even) never improves fault tolerance, but going from that even number to N+2 (the next odd number) does: this is why the standard etcd cluster sizes recommended are 3, 5, or 7 — each represents a genuine step up in fault tolerance, while their even-numbered neighbors (4, 6) offer no benefit over the odd number just below them.

More members also means slower writes, adding a real cost to over-provisioning: every write requires agreement from a majority of members, so more members generally means more network round-trips and coordination overhead per write — this is why etcd clusters aren't scaled arbitrarily large "for more redundancy"; there's a genuine latency cost to more members that isn't offset by a proportional fault-tolerance gain once you're past the point where quorum math stops improving.

This same logic applies to control-plane node count generally, not just etcd specifically, when etcd is co-located (stacked topology): since a stacked-topology control-plane node runs both etcd and the API server, the same odd-number reasoning that applies to etcd's quorum directly determines the recommended control-plane node count (3, 5, or 7) for the whole control plane, not just its data layer.

Practical guidance: choose 3 for most production clusters (tolerates 1 failure, standard and well-tested), 5 for environments needing to tolerate 2 simultaneous failures (larger, more critical deployments, or those spanning more failure domains like availability zones where correlated failures are more plausible) — and specifically avoid 4 or 6, since they cost more than the odd number just below them while providing zero additional fault tolerance.

• etcd quorum is floor(N/2) + 1 — a strict majority of members must be available for the cluster to accept writes.
• Going from an odd N to N+1 (an even number) never improves fault tolerance; going from that even number to N+2 (the next odd number) does.
• 3 tolerates 1 failure, 5 tolerates 2 — 4 provides no more tolerance than 3, and 6 provides no more than 5, while both cost more.
• More members also means more coordination overhead per write, so scaling etcd size "for more redundancy" past the point where quorum math actually improves is pure cost with no benefit.

• etcd: FAQ — What is failure tolerance?
• Kubernetes: Options for Highly Available Topology