性能测试结果
| 客户端节点数量 | vCPU | 内存 | 磁盘大小 | 建议 etcd 节点数 | etcd 客户端连接数 | etcd 请求数/每秒 | 数据量 | 读 QPS（线性） | 写 QPS | 读 QPS（串行） |
|---|---|---|---|---|---|---|---|---|---|---|
| 50 | 2核 | 8G | 20G SSD | 5 | <100 | 200 | 约100M | 12509.93 | 21989.2 | 20125.71 |
| 250 | 4核 | 16G | 20G SSD | 5 | <500 | 1000 | 约500M | 23043.92 | 45052.9 | 33582.68 |
| 1000 | 8核 | 32G | 20G SSD | 7 | <1500 | 10000 | 约1GB | 44721.41 | 47735.1 | 61122.55 |
| 3000 | 16核 | 64G | 20G SSD | 9 | >1500 | >10000 | >1GB | 66219.35 | 39326.5 | 169194.62 |
说明
读写 QPS 为 etcd 100 连接，1000 客户端 下的 etcd benchmark 结果。
- 写为 all members。
- 读取测试中为了一致性，线性化（Linearizable）读取请求要通过集群成员的所有节点来获取最新的数据。串行化（Serializable）读取请求是通过任意单台 etcd 节点来提供服务，而不是成员的所有节点。串行化比线性化读取更节省资源，但是可能读取到的是过期数据。
推荐 etcd 集群配置
| K8S 集群规模 | etcd 节点数量 | CPU | 内存 | 磁盘 |
|---|---|---|---|---|
| 工作节点数量：100 个 | 5 | 4核 | 16G | 20GB SSD |
| 工作节点数量：250 个以上 （或者需要 watchers 的数量增加，etcd 数据量增大） | 7 | 8核 | 32G | 20GB SSD |
CPU
典型的集群需要 2核 ~ 4核才能顺利运行。
重负载的 etcd 部署，每秒服务数千个客户端或数万个请求，往往受 CPU 限制，因为 etcd 可以处理来自内存的请求，比如将数据写入落盘。如此繁重的部署通常需要 8~16 个 CPU。
内存
etcd 集群将积极缓存键值数据到内存，并同时花费大部分其余的内存跟踪观察者（watchers）。
通常 8GB 就足够了。
对于具有数千个观察者和数百万个键的大量部署，可以相应地分配 16GB ~ 64GB 内存。
磁盘
官方推荐使用 SSD 类型的磁盘，性能最佳。
etcd quota-backend-bytes（存储大小限制）
缺省值目前为 2GB，在工作节点数达 1000 个时，建议设置为 4GB（最大8GB）。