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