第 3 章 确保可靠的 etcd 性能和可扩展性
为确保使用 etcd 的最佳性能,务必要了解会影响性能的条件,包括节点扩展、领导选举、日志复制、调整、延迟、网络 jitter、对等往返时间、数据库大小和 Kubernetes API 事务率。
3.1. etcd 的领导选举机制和日志复制 复制链接链接已复制到粘贴板!
复制链接链接已复制到粘贴板!
etcd 是一个一致的分布式键值存储,作为复制节点集群运行。根据 Raft 算法,etcd 选择一个节点作为领导(leader),其他节点为跟随者(follower)。领导机维护系统的当前状态,并确保跟随者保持最新状态。
领导节点负责日志复制。它处理从客户端传入的写入事务,并写一个 Raft 日志条目,然后再将其广播到跟随者。
当一个 etcd 客户端(如 kube-apiserver)连接到一个 etcd 成员,它在请求一个需要仲裁的操作(如写一个值),如果 etcd 成员是跟随者,它会返回一个信息声明相关的事务需要转给领导。
当 etcd 客户端从需要仲裁的领导请求一个操作(如写一个值),领导会保持客户端的连接,同时写入本地 Raft 日志,将日志广播到跟随者,并等待大多数跟随者确认已提交日志并且没有错误。领导将确认发送到 etcd 客户端并关闭会话。如果从跟随者收到失败通知且没有满足共识,则领导会将错误消息返回到客户端并关闭会话。