https://mp.weixin.qq.com/s/lD2b-DZyvRJ3qWqmlvHpxg
从零开始入门 K8s | etcd 性能优化实践
如上图所示，一个集群有三个节点：一个 Leader 和两个 Follower。每个节点通过 Raft 算法同步数据，并通过 boltdb 存储数据。当一个节点挂掉之后，另外的节点会自动选举出来一个 Leader，保持整个集群的高可用特性。Client 可以通过连接任意一个节点完成请求。
理解 etcd 性能
首先我们来看一张图：
上图是一个标准的 etcd 集群架构简图。可以将 etcd 集群划分成几个核心的部分：例如蓝色的 Raft 层、红色的 Storage 层，Storage 层内部又分为 treeIndex 层和 boltdb 底层持久化存储 key/value 层。它们的每一层都有可能造成 etcd 的性能损失。
首先来看 Raft 层，Raft 需要通过网络同步数据，网络 IO 节点之间的 RTT 和 / 带宽会影响 etcd 的性能。除此之外，WAL 也受到磁盘 IO 写入速度影响。
再来看 Storage 层，磁盘 IO fdatasync 延迟会影响 etcd 性能，索引层锁的 block 也会影响 etcd 的性能。除此之外，boltdb Tx 的锁以及 boltdb 本身的性能也将大大影响 etcd 的性能。
从其他方面来看，etcd 所在宿主机的内核参数和 grpc api 层的延迟，也将影响 etcd 的性能。
etcd 性能优化 -server 端
下面具体来介绍一下 etcd server 端的性能优化。
1. etcd server 性能优化-硬件部署
-
server 端在硬件上需要足够的 CPU 和 Memory 来保障 etcd 的运行；
-
其次，作为一个非常依赖于磁盘 IO 的数据库程序，etcd 需要 IO 延迟和吞吐量非常好的 ssd 硬盘，etcd 是一个分布式的 key/value 存储系统，网络条件对它也很重要；
-
最后在部署上，需要尽量将它独立的部署，以防止宿主机的其他程序会对 etcd 的性能造成干扰。
附：etcd 官方推荐的配置要求信息。
2. etcd server 性能优化-软件
etcd 软件分成很多层，下面根据不同层次进行性能优化的简单介绍。想深度了解的同学可以自行访问下面的 GitHub pr 来获取具体的修改代码。
- 首先是针对于 etcd 的内存索引层：优化内部锁的使用减少等待时间。原来的实现方式是遍历内部引 BTree 使用的内部锁粒度比较粗，这个锁很大程度上影响了 etcd 的性能，新的优化减少了这一部分的影响，降低了延迟；
- 针对于lease 规模使用的优化：优化了 lease revoke 和过期失效的算法，将原来遍历失效 list 时间复杂度从 O(n) 降为 O(logn)，解决了 lease 规模化使用的问题；
- 最后是针对于后端 boltdb的使用优化：将后端的 batch size limit/interval 进行调整，这样就能根据不同的硬件和工作负载进行动态配置，这些参数以前都是固定的保守值；
- 还有一点是由谷歌工程师优化的完全并发读特性：优化调用 boltdb tx 读写锁使用，提升读性能。
3. 基于 segregated hashmap 的 etcd 内部存储 freelist 分配回收新算法
其它的性能优化也非常多，这里我们重点介绍一下由阿里巴巴贡献的一个性能优化。这个性能优化极大地提升了 etcd 内部存储的性能，它的名字叫做：基于 segregated hashmap 的 etcd 内部存储 freelist 分配回收新算法。
上图是 etcd 的一个单节点架构，内部使用 boltdb 作为持久化存储所有的 key/value，因此 boltdb 的性能好坏对于 etcd 的性能好坏起着非常重要的作用。在阿里巴巴内部，我们大量使用 etcd 作为内部存储元数据，在使用过程中我们发现了 boltdb 的性能问题，这里分享给大家。
-
针对于 Put 操作避免使用大 value，精简精简再精简，例如 K8s 下的 crd 使用；
-
其次，etcd 本身适用及存储一些不频繁变动的 key/value 元数据信息。因此客户端在使用上需要避免创建频繁变化的 key/value。这一点例如 K8s下对于新的 node 节点的心跳数据上传就遵循了这一实践；
-
最后，我们需要避免创建大量的 lease，尽量选择复用。例如在 K8s下，event 数据管理：相同 TTL 失效时间的 event 同样会选择类似的 lease 进行复用，而不是创建新的 lease。
本文总结
本文内容到这里就结束了，这里为大家总结一下：
- 首先我们理解了 etcd 性能背景，从背后原理了解潜在的性能瓶颈点；
- 解析 etcd server 端性能优化，从硬件/部署/内部核心软件算法等方面优化；
- 了解 etcd client 使用最佳实践；
最后希望各位同学读完本文后，能够有所收获，为你们运行一个稳定而且高效的 etcd 集群提供帮助。
etcd improvements
为了解决这些问题，阿里云容器平台在各方面都做了很大的努力，改进 Kubernetes 在大规模场景下的性能。
首先是 etcd 层面，作为 Kubernetes 存储对象的数据库，其对 Kubernetes 集群的性能影响至关重要。
-
第一版本的改进，我们通过将 etcd 的数据转存到 tair 集群中，提高了 etcd 存储的数据总量。但这个方式有一个显著的弊端是额外增加的 tair 集群，增加的运维复杂性对集群中的数据安全性带来了很大的挑战，同时其数据一致性模型也并非基于 raft 复制组，牺牲了数据的安全性。
-
第二版本的改进，我们通过将 API Server 中不同类型的对象存储到不同的 etcd 集群中。从 etcd 内部看，也就对应了不同的数据目录，通过将不同目录的数据路由到不同的后端 etcd 中，从而降低了单个 etcd 集群中存储的数据总量，提高了扩展性。
-
第三版本的改进，我们深入研究了 etcd 内部的实现原理，并发现了影响 etcd 扩展性的一个关键问题在底层 bbolt db 的 page 页面分配算法上：随着 etcd 中存储的数据量的增长，bbolt db 中线性查找“连续长度为 n 的 page 存储页面”的性能显著下降。
为了解决该问题，我们设计了基于 segregrated hashmap 的空闲页面管理算法，hashmap 以连续 page 大小为 key, 连续页面起始 page id 为 value。通过查这个 segregrated hashmap 实现 O(1) 的空闲 page 查找，极大地提高了性能。在释放块时，新算法尝试和地址相邻的 page 合并，并更新 segregrated hashmap。更详细的算法分析可以见已发表在CNCF 博客的博文。
过这个算法改进，我们可以将 etcd 的存储空间从推荐的 2GB 扩展到 100GB，极大地提高了 etcd 存储数据的规模，并且读写无显著延迟增长。
除此之外，我们也和谷歌工程师协作开发了 etcd raft learner（类 zookeeper observer）/fully concurrent read 等特性，在数据的安全性和读写性能上进行增强。这些改进已贡献开源，将在社区 etcd 3.4 版本中发布。
API Server improvements
Efficient node heartbeats
在 Kubernetes 集群中，影响其扩展到更大规模的一个核心问题是如何有效的处理节点的心跳。在一个典型的生产环境中 (non-trival)，kubelet 每 10s 汇报一次心跳，每次心跳请求的内容达到 15kb（包含节点上数十计的镜像，和若干的卷信息），这会带来两大问题：
-
心跳请求触发 etcd 中 node 对象的更新，在 10k nodes 的集群中，这些更新将产生近 1GB/min 的 transaction logs（etcd 会记录变更历史）；
-
API Server 很高的 CPU 消耗，node 节点非常庞大，序列化/反序列化开销很大，处理心跳请求的 CPU 开销超过 API Server CPU 时间占用的 80%。
