Kubernetes生产集群双master节点的etcd信息共享及部署机制问询

双Master节点是通过etcd集群的Raft共识算法实现信息共享的。etcd作为分布式键值存储，多节点组成集群后，会通过Raft协议同步数据，保证所有节点的数据一致性，Master节点通过连接etcd集群来获取或写入集群状态数据。

疑问1：配置2个master节点时，它们是否共享etcd数据库？ #

• 并非共享同一个物理数据库文件，而是通过etcd集群的分布式同步机制，让各个etcd节点拥有完全一致的数据副本。从业务视角看，整个etcd集群对外呈现为统一数据源，所有Master节点连接该集群读写数据，实现逻辑上的“共享”。

疑问2：是每个master节点各自拥有etcd副本，还是etcd需部署在独立机器上？其具体工作机制是怎样的？ #

• 两种部署方式都存在，但生产环境更推荐etcd独立部署（etcd节点与Master节点分属不同机器）——因为etcd对CPU、内存、磁盘IO资源敏感，和kube-apiserver、controller-manager等Master组件混部易引发资源竞争，影响稳定性。
• 若每个Master节点自带etcd副本，这两个etcd节点会组成2节点etcd集群（注意：etcd集群最优节点数为奇数，2节点集群存在脑裂风险，生产环境不建议使用）。
• 具体工作机制：
  • etcd集群通过Raft协议选举主节点，所有写入操作先发送至主节点，主节点将操作复制到其他从节点；当超过半数节点确认写入成功后，操作才会被提交。
  • Master节点的kube-apiserver会配置etcd集群的端点列表，当某个etcd节点故障时，kube-apiserver会自动切换至其他可用节点，保证服务连续性。

疑问3：若其中一个master节点故障，另一个master节点是否拥有完整的etcd信息？ #

• 只要etcd集群本身处于可用状态（比如2节点集群中至少1个etcd节点存活，或独立部署的etcd集群有足够节点存活），正常的Master节点连接etcd集群就能获取完整数据。
• 特殊情况：如果是Master自带etcd的2节点集群，当其中一个Master+etcd节点故障，剩余节点因无法满足Raft“半数以上确认”的要求，会进入只读状态，但依然保留完整的数据副本。

内容的提问来源于stack exchange，提问作者Ohad