跳过正文
icon

Sealos,在云桌面中运行分布式应用程序,像使用个人电脑一样使用云

icon

去看看👀

icon

扫码加入微信群,和云原生大佬们一起探讨云原生和不可描述的事情!

wechat qr code
重磅推荐❗
icon
 
舔狗日记

etcd 集群大小迷思
  1. 博客/

etcd 集群大小迷思

·1571 字·4 分钟· · ·
云原生 Etcd Kubernetes
米开朗基杨
作者
米开朗基杨
云原生搬砖师 & Sealos 开发者布道师 & FastGPT 熟练工
Table of Contents
The Magic School Bus
gptgod
FastGPT
Contact me

etcd 使用 raft 协议保证各个节点之间的状态一致。根据 raft 算法原理,节点数目越多,会降低集群的写性能。这是因为每一次写操作,需要集群中大多数节点将日志落盘成功后,Leader 节点才能将修改内部状态机,并返回将结果返回给客户端。但是根据 etcd 分布式数据冗余策略,集群节点越多,容错能力(Failure Tolerance)越强。所以关于集群大小的优化,其实就是容错和写性能的一个平衡。

集群的大小指集群节点的个数。

你可能会在很多文章中看到 etcd 推荐使用奇数作为集群节点个数。因为奇数个节点与和其配对的偶数个节点相比(比如 3 节点和 4 节点对比),容错能力相同,却可以少一个节点。但却没有人告诉你为什么会这样,今天我就给你们带来详细解读。

选举方法
#


首先简单介绍一下 etcd 的选举方法:

  • 初始启动时,节点处于 follower 状态并被设定一个 election timeout,如果在这一时间周期内没有收到来自 leader 的 heartbeat,节点将发起选举:将自己切换为 candidate 之后,向集群中其它 follower 节点发送请求,询问其是否选举自己成为 leader
  • 当收到来自集群中过半数节点的接受投票后,节点即成为 leader,开始接收保存 client 的数据并向其它的 follower 节点同步日志。如果没有达成一致,则 candidate 随机选择一个等待间隔(150ms ~ 300ms)再次发起投票,得到集群中半数以上 follower 接受的 candidate 将成为 leader。
  • leader 节点依靠定时向 follower 发送 heartbeat 来保持其地位。
  • 任何时候如果其它 follower 在 election timeout 期间都没有收到来自 leader 的 heartbeat,同样会将自己的状态切换为 candidate 并发起选举。每成功选举一次,新 leader 的任期(Term)都会比之前 leader 的任期大 1。
请注意:这里说的超过半数节点接受投票,是包括 candidate 自身在内的!而且这里的半数是以原集群大小作为总数来计算的!举个例子:假设某个 etcd 集群有 N 个节点,挂了一个节点之后,如果重新发起选举,一定要有超过 N/2 个节点接受投票(包括 candidate 在内),即最少需要 (N+1)/2 个节点接受投票,参加选举的节点才能成为 leader。

集群大小与容错
#


假设有两个 etcd 集群,分别是 2 个节点和 1 个节点,2 节点集群需要所有节点接受投票才能选举成功(N=2),只要有一个节点发生故障,etcd 集群就会变成不可用状态,因为这时不可能选举成功。因此 2 节点集群的容错能力不如单节点集群,2 节点集群的容错能力为 0%

我们把“超过半数节点接受投票的节点数量”称为 majority

同样的方式,比较 3 节点集群和 4 节点集群。对于 3 节点集群来说,如果其中一个节点发生故障,majority 仍然是 2,集群依然可用。而对于 4 节点集群而言,majority 是 3,只允许一个节点发生故障,如果有两个节点发生故障,majority 就会变成 2,而 2 不满足 > N/2 的要求(N=4)。现在你应该理解为什么奇数个节点与和其配对的偶数个节点相比(比如 3 节点和 4 节点对比),容错能力相同了。

这里能选择偶数个节点吗? 最好不要这样。原因有二:

  • 偶数个节点集群不可用风险更高,表现在选主过程中,有较大概率获得等额选票,从而触发下一轮选举。
  • 偶数个节点集群在某些网络分割的场景下无法正常工作。试想,当网络分割发生后,将集群节点对半分割开。此时集群将无法工作。按照 raft 协议,此时集群写操作无法使得大多数节点同意,从而导致写失败,集群无法正常工作。

当网络分割后,etcd 集群如何处理的呢?

  • 当集群的 Leader 在多数节点这一侧时,集群仍可以正常工作。少数节点那一侧无法收到 Leader 心跳,也无法完成选举。
  • 当集群的 Leader 在少数节点这一侧时,集群仍可以正常工作,多数派的节点能够选出新的 Leader, 集群服务正常进行。

当网络分割恢复后,少数派的节点会接受集群 Leader 的日志,直到和其他节点状态一致。

所以综合考虑性能和容错能力,etcd 官方文档推荐的 etcd 集群大小是 3, 5, 7。至于到底选择 3,5 还是 7,根据需要的容错能力而定。

关于节点数和容错能力对应关系,如下表所示:

集群大小最大容错
10
31
41
52
62
73
83
94
-------他日江湖相逢 再当杯酒言欢-------

相关文章

Kubernetes 设计与开发原则
·3292 字·7 分钟·
云原生 Kubernetes
深入理解 Kubernetes 资源限制:CPU
·3856 字·8 分钟·
云原生 Cgroup Kubernetes
Kubernetes DNS 高阶指南
·3148 字·7 分钟·
云原生 Kubernetes
kubectl 创建 Pod 背后到底发生了什么?
·11207 字·23 分钟·
云原生 Kubernetes
Kubernetes 中 Pod 的生命周期管理
·1732 字·4 分钟·
云原生 Kubernetes
Kube-router 使用指南
·3296 字·7 分钟·
云原生 Kubernetes LVS

公众号二维码