ETCD 是如何成为一个高可用系统的，即使它使用的是 CP 算法 Raft？

Posted 2023-02-19

【中文标题】ETCD 是如何成为一个高可用系统的，即使它使用的是 CP 算法 Raft？

【英文标题】：How is ETCD a highly available system, even though it uses Raft which is a CP algorithm?

【发布时间】：2022-01-17 12:57:35

【问题描述】：

这是来自Kubernetes documentation：

一致和高可用键值存储用作 Kubernetes' 所有集群数据的后备存储。

Kubernetes 内部是否有单独的机制来提高 ETCD 的可用性？或者说，ETCD 是否使用了允许这种超能力的 Raft 的修改版本？

【问题讨论】：

“CP算法”是什么意思？从标题？你能解释一下吗？ Raft 是一种共识算法。

这是在 CAP 定理的上下文中。我可以在这里解释一下，但如果你自己查一下，你会更清楚。

【参考方案1】：

涉及到etcd的细节，最好使用official etcd documentation：

etcd 是一种高度一致的分布式键值存储，它提供了一种可靠的方式来存储需要由分布式系统或机器集群访问的数据。它在网络分区期间优雅地处理领导者选举，并且可以容忍机器故障，即使在领导者节点中也是如此。

这里没有提到这是高可用性。至于容错，你会发现关于这个话题的一段非常好的here：

只要可以建立成员仲裁，etcd 集群就会运行。如果由于短暂的网络故障（例如，分区）导致仲裁丢失，一旦网络恢复并恢复仲裁，etcd 会自动安全地恢复； Raft 强制执行集群一致性。对于掉电，etcd 将 Raft 日志持久化到磁盘； etcd 将日志重播到故障点并恢复集群参与。对于永久性硬件故障，可以通过runtime reconfiguration将节点从集群中移除。

建议集群中的成员数为奇数。奇数大小的集群容忍的故障数量与偶数大小的集群相同，但节点更少。

你也可以找到关于understanding etcd的非常好的文章：

Etcd 是一个强一致性系统。它为事务提供Linearizable 读写和Serializable 隔离。更具体地说，根据PACELC 定理，CAP 定理中表达的思想的扩展，它是一个 CP/EC 系统。 它针对正常情况下的延迟一致性和分区情况下的可用性一致性进行了优化。

也看这张图：

【讨论】：

很好的解释。

那么，ETCD 不高可用就是你的意思，K8s 文档需要更正吗？

这就是它的样子。 k8s 文档看起来不是很精确。