你的操作本身没有错误，问题出在2节点ETCD集群的先天架构缺陷上，咱们来拆解一下：

核心原因：Raft协议的Quorum（法定人数）要求 #

ETCD基于Raft共识协议运行，这个协议要求必须有超过半数的节点在线并达成一致，才能处理需要共识的操作（包括默认的线性一致性读、所有写操作）。

对于2节点集群来说，法定人数的计算公式是 quorum = (节点数/2) + 1，也就是 (2/2)+1=2——意味着必须两个节点都在线，集群才能正常处理请求。当你停掉master01后，只剩master02一个节点，达不到法定人数，所以即使单个节点还活着，集群也无法完成共识流程，导致你的get请求超时。

临时 workaround（仅适用于读场景） #

如果只是需要读取数据（对一致性要求不高的场景），可以调整etcdctl的读一致性级别为stale（过时读），它允许从单个可用节点读取本地数据，不需要经过共识流程：

ETCDCTL_API=3 etcdctl --endpoints=http://10.1.1.22:2379 --consistency=s get date

注意：stale读可能拿到不是集群最新的数据，适合对数据实时性要求不高的场景。

长期解决方案：扩容到3节点集群 #

这是ETCD生产环境的推荐配置：3节点集群的法定人数是2，即使其中一个节点故障，剩下的两个节点依然能达成共识，集群可以正常处理所有读写请求。扩容的核心步骤大概是：

• 新增一个节点（比如master03），配置加入现有集群
• 用etcdctl --cluster=true endpoint health确认集群健康状态
• 后续操作使用包含3个节点的endpoints列表

补充说明 #

你之前在集群正常时的操作都是标准正确的：用etcdctl endpoint health检查集群状态、指定多个endpoints执行读写，这些都没问题。问题完全出在2节点集群的架构局限性上，不是你的操作失误。

内容的提问来源于stack exchange，提问作者tinashe.chipomho