跨两站点的 Kubernetes 集群需要三个 etcd 投票成员吗？

三台控制平面虚拟机会让人觉得有三份熬过糟糕夜晚的保障。其实并非如此，而这两种认知之间的差距，正是把一个整洁的三节点设计变成“一栋楼断电就停止接受写入”的集群的原因。站点之间的 VPN 链路让机器彼此可达，却掩盖而非解决问题。票数按 etcd 成员计算，其中两个成员仍可能位于同一个交换机、同一台 UPS 和同一条上联之后。

三个控制平面节点，一个故障域

你运行 kubectl get nodes，看到三个控制平面条目，就把集群登记为高可用。这个数字描述的是可调度容量，而不是生存能力。在没有外部 etcd 的 kubeadm 中，每个控制平面节点也承载一个成员，所以三个节点确实给你三个投票成员。这些成员是否会独立故障，是节点列表无法回答的另一个问题。

同一台宿主机上的两台虚拟机、同一路供电上的两个机柜、同一家运营商的两条上联：每一对都是共用两个主机名的同一个域。写下部署拓扑，并标出每个投票成员共享什么——宿主机、PDU、机柜顶部交换机、存储阵列、NAT 设备、VPN 集中器。然后在纸上移除每个共享对象，重新统计剩下的票数。一台主机故障就失去两个投票成员的集群，一直都是单投票成员集群；只是此前没人问过它这个问题。

两站点拆分能承受什么、不能承受什么

当三个投票成员按二比一分布在两个站点时，另一站点消失后较大一侧仍保有法定人数，而只有一个投票成员的一侧永远没有。这种不对称是算术，不是调优。任何基于多数派的 etcd 集群只要恰好分布在两个独立站点上，就无法通过“失去任一站点仍能提交”的测试，因为两侧必须同时握有过半票数。

下表是看清你实际买下哪些故障的最快方式。每一行都这样读：如果今晚整行消失，幸存者还能提交一次写入吗？

为什么隧道从不增加票数

VPN 是传输，不是成员。它可以让远程投票成员可达，也可以把分区变成看起来像缓慢超时的东西，这就是它对法定人数的全部贡献。它增加的是成本，因为每次提交都必须跨越链路，etcd 要为触及 raft 日志的写入支付这个往返。抖动的路径会把复制变成重试和选举。

分区是人们期待奇迹的地方，所以要讲清楚。如果链路断开时旧领导者在单投票成员一侧，那一侧无法提交，领导者在选举超时后下台，而双投票成员一侧会选出替代者。etcd 的故障模式指南直白地描述了这种行为：多数一侧继续服务，隔离一侧没有第二个可写集群。

决定你买的是哪种中断

当站点 A 是主站点，而你接受失去它意味着在有人行动之前失去控制平面写入时，二加一就是合理设计。把它变成缺陷的是让这个决定保持隐含。写进 runbook：你的控制平面能扛住哪个站点，以及另一个站点在 03:00 宕机时运维人员该怎么做。

如果要求改为“任一站点都可以故障”，部署必须在每个站点都占多数，而三个投票成员分布在两个站点做不到。你要么增加真正独立的第三个域——另一家云厂商的小区域只要路径稳定就行——要么拆成两个各自拥有 etcd 的集群，并接受这种拆分带来的运维成本。任何“见证者”捷径都绕不开这一点：etcd 没有轻量仲裁成员，所以第三个投票成员是拥有自己磁盘、内存和网络需求的完整成员。在图上画一个标着“见证者”的方框并不能造出见证者。

法定人数不等于服务

etcd 法定人数只保证 API 服务器还能接受写入，仅此而已。负载均衡器的健康检查、Ingress、跨隧道的 CNI 可达性、卷挂载可用区以及应用复制，各自都需要自己的答案。一个集群可以保有干净的多数，却仍然无法为用户提供任何有用的服务。

然后确认你以为拥有的成员关系，因为拓扑图会漂移：

kubectl -n kube-system get pods -l component=etcd -o wide
kubectl get endpoints kube-apiserver -n default
etcdctl member list -w table

把成员列表与部署图对照。如果两个成员解析到同一台主机或同一个机柜，错的是图而不是集群；围绕错误拓扑调整规模，只会买到同一种中断的更贵版本。

在批准任何三投票成员设计之前，先回答四个问题：有多少投票成员会一起断电，失去哪个站点仍留有多数，隧道断开时领导者在哪里，幸存站点还能做什么。其中任何一项“不确定”，都意味着集群还不是高可用。那只是三台运气不错的机器。