A library consortium runs three control-plane nodes with stacked etcd. One control-plane VM fails. Why can the API often remain available?
Select an answer to reveal the explanation.
Short Explanation
Three etcd voters are like a three-judge panel—lose one and the other two can still outvote silence. That’s why odd counts and HA control planes tolerate a single missing member. Lose a second without recovery and quorum—and writes—go away fast.
Full Explanation
With three stacked etcd members on a library consortium control plane, the API can often remain available when one control-plane VM fails because an odd-sized etcd cluster can still meet majority quorum after losing one member. Three judges can outvote silence; that is why HA control planes tolerate a single missing member. Kubernetes does not disable etcd quorum checks whenever any control-plane node is NotReady. A single surviving apiserver does not reliably rewrite etcd membership to one without operator action every time. Workers do not cache the full API indefinitely such that etcd quorum becomes optional during node loss. Exam caveat: Losing a second member without recovery risks losing quorum and writes—monitor membership. Operational check: Simulate or review failure of one CP node, confirm etcdctl endpoint health/member list still shows quorum, and verify API reads/writes via the HA endpoint. In municipal platform operations, record the rationale in the change ticket so future on-call staff know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that the same control still holds under the cluster’s current minor version and addon revisions used by the civic platform team.