Kubernetes 平面组件 etcd

etcd

---

etcd 是高可用的键值对的分布式安全存储系统，用于持久化存储集群中所有的资源对象，例如集群中的Node、Service、Pod 的状态和元数据，以及配置数据等。为了持久性和高可用性，生产环境中的etcd 集群成员需分别在多个节点上运行，并定期对其进行备份。

如图1-10 所示，在多个etcd 成员组成的etcd 集群中，etcd 成员间使用Raft 共识算法复制请

求并达成协议。

对于etcd，这里有几个概念：领导者、选举和任期。任何etcd 集群成员都可以处理读请求，不需要共识。但只有领导者才能处理写请求，包括更改、新增、删除等。

如图1-10所示，当来自客户端API Server 的写请求被提交到etcd 成员处时，如果它不是领导者，那么它会将此请求转移给领导者。领导者会将请求复制到集群的其他成员中进行仲裁，当超过半数成员同意更改时，领导者才将更改后的新值提交到日志wal 中，并通知集群成员进行相应的写操作，将日志中的新值写入磁盘中。

每个集群在任何给定时间都只能有一个领导者。如果领导者不再响应，那么其余成员在预定的选举计时器超时后会开始新的选举，将自己标记为候选者，并请求其他节点投票来开始新的选举。每个节点为请求其投票的第一个候选者投票。

如果候选人从集群中的大多数节点获得投票，那么它将成为新的领导者。每个节点维护的选举计时器的超时时间不同，因此第一个候选人通常会成为新的领导者。

但是，如果存在多个候选人并获得相同数目的选票，则现有的选举任期将在没有领导人的情况下结束 ，而新任期将以新的随机选举计时器开始。因此，我们建议在部署etcd 集群时采用奇数个

成员为佳。

根据Raft 的工作机制，每个写请求需要集群中的每个成员做仲裁，因此我们建议etcd 集群成员数量不要超过7 个，推荐是5 个，个数越多仲裁时间会越多，写的吞吐量会越低。

如果集群中的某个成员处理请求特别慢，就会让整个etcd 集群不稳定，且性能受到限制。因此，我们要实时监测每个etcd 成员的性能，及时修复或者移除性能差的成员。