大集群
大集群主要问题有 b+tree重平衡和分解过程中超过20Gi的性能瓶颈,是O(n)复杂度,启动耗时增大,放大expensive request的影响。
其中最重要的就是最大程度地减少 expensive request。
对几十万级别的对象数量来说,按标签还是获取所有cr等场景时,很容易造成 etcd 和 kube-apiserver OOM 和丢包,乃至雪崩等问题发生。 可采取措施:资源按 namespace 拆分,分页查,Informer 机制,Watch bookmark 机制,利用Notify 机制实现高效的 Watch 恢复机制。
etcd 默认心跳间隔时间(heartbeat-interval)是 100ms, 默认竞选超时时间(election timeout)是 1000ms, 你需要根据实际部署环境、业务场景适当调优,否则就很可能会频繁发生 Leader 选举切换,导致服务稳定性下降
etcd proxy扩展性能,可以实现 cheap/expensive read request 隔离。
etcd 是一个对磁盘 IO 性能非常敏感的存储系统,磁盘 IO 性能不仅会影响 Leader 稳定性、写性能表现,还会影响读性能。线性读性能会随着写性能的增加而快速下降。
etcdctl get key --rev etcd有三个磁盘存储 etcd db(异步批量提交的事物数据),WAL(重启后可恢复),snapshot(raftLog默认10w条拍一次snapshot,从而降低内存开销)
etcd常见报错原因
当一个请求超过 300ms 时,就会打印整个请求信息。
etcdserver: too many requests
任何请求提交到Raft 模块,都会做Preflight Check,当Raft 模块已提交的日志索引(committed index)比已应用到状态机的日志索引(applied index)超过了 5000,会打印此日志。
apply request took too long
处理写请求put/txn流程 或 处理读请求 range 流程时,若一个请求执行超过 100ms 时,则会打印此日志。
waiting for ReadIndex response took too long, retrying
线性读时向raft模块发送readIndex请求来确保本节点状态机的已应用日志索引 (applied index) 大于等于 Leader 的已提交日志索引,等待readIndex请求返回时超时,超时时间500s。
ignored out-of-date read index response; local node read indexes queueing up and waiting to be in sync with leader
{"level":"warn","ts":"2023-09-13T00:00:20.135Z","caller":"etcdserver/v3_server.go:817","msg":"ignored out-of-date read index response; local node read indexes queueing up and waiting to be in sync with leader","sent-request-id":13287178521848115518,"received-request-id":13287178521848115504}
sending database snapshot to client
执行etcdctl snapshot时打印打信息。
etcd启动参数最佳实践
--snapshot-count=100000,默认是1000,触发raftLog到磁盘的已提交提案数
--heartbeat-interval=1000,默认是100ms,心跳间隔
--election-timeout=5000,默认是1000ms,选举超时
备注
etcd的键值被删除或更新时,旧的键值对不会被立即删除而是被标记为无效。compact能够清理被标记为无效的键值对,从而重复利用,但不会释放给系统;defrag会清理数据存储的碎片并释放给系统。kube-apiserver设置了--etcd-compaction-interval=5m0s,每5分钟清理一次
fsync函数会同步内存中所有已修改的文件数据到储存设备。
随机IO与顺序IO
当读取磁盘block时,要经历寻道,旋转延迟,传输三个步骤才能读取完这个block的数据。而对于下一个block访问它会同样经历寻道、旋转、延时,传输才能读取完这个block的数据, 这种方式的IO叫做随机IO。
但是如果下一个block的起始扇区刚好在上一个block的后面,就不需要寻道、旋转,直接传输即可,这种就叫顺序IO。
并发读特性的核心原理是创建读事务对象时,它会全量拷贝当前写事务未提交的 buffer 数据,并发的读写事务不再阻塞在一个 buffer 资源锁上,实现了全并发读。最重要的是,写事务也不再因为 expensive read request 长时间阻塞,有效的降低了写请求的延时。