etcd存储占用是否随键值线性增长？压缩机制的边界与效能探究

背景观察 #

在对Kubernetes集群进行压力测试时，发现向集群添加大量数据后，etcd快照的大小增长十分有限：

收集快照使用的命令：

etcdctl --endpoints="https://localhost:2379" --cacert="/etc/kubernetes/pki/etcd/ca.crt" --cert="/etc/kubernetes/pki/etcd/server.crt" --key=/etc/kubernetes/pki/etcd/server.key snapshot save jay.db

多次操作后的快照大小对比：

root@tkg-mgmt-vsphere-20221014024846-control-plane-mp642:/home/capv# ls -altr jay*
-rw------- 1 root root 34975776 Oct 24 17:33 jay.db
-rw------- 1 root root 35061792 Oct 24 17:55 jay2.db
-rw------- 1 root root 35217440 Oct 24 18:05 jay3.db

首先明确结论：etcd的存储占用不会随键值数量完全线性增长，核心原因是它内置了自动数据压缩机制，会主动清理非必要的历史数据，从而控制存储规模。

核心问题解答 #

1. 大规模Kubernetes集群中，压缩机制的作用边界与限制 #

etcd的压缩机制主要针对**历史数据（旧Raft日志、键值旧版本）**进行清理，在大规模集群中的作用边界和限制如下：

• 仅处理非活跃数据：压缩不会减少当前正在使用的活跃数据体积。如果集群持续新增大量全新的活跃对象（如数万个独立Pod、ConfigMap），活跃数据总量会线性增长，快照大小也会随之上升——压缩只能避免历史数据无限堆积，没法压缩正在使用的真实数据。
• 受配置参数约束：压缩的效果取决于--auto-compaction-mode（时间/版本模式）和--auto-compaction-retention（保留期限/版本数）的配置。如果保留期限过长（比如保留30天的历史版本），或者Raft日志保留条数过多，历史数据的堆积仍会导致存储占用上升，需要根据集群的实际操作频率调整参数。
• 存在性能开销边界：当集群规模达到数万个对象以上时，高频压缩操作会占用etcd的CPU和IO资源，若压缩触发过于频繁，可能会影响etcd的读写响应速度，需要在存储占用控制和服务性能之间做平衡。
• 不处理重复活跃数据：压缩机制不会对重复的活跃数据做去重。比如创建1000个结构完全相同的ConfigMap，这些重复数据会真实占用存储，压缩机制无法自动合并或缩减这部分体积。

2. 相似/重复信息增多时，压缩机制的效果变化 #

压缩机制的效果不会随相似或重复活跃信息的增多而持续提升，原因如下：

• 压缩的核心目标是清理历史版本和已提交的旧Raft日志，而相似/重复的活跃数据属于当前正在使用的有效数据，不在压缩的处理范围内。
• 只有当这些重复数据被删除、产生历史版本时，压缩才会清理它们的旧版本，但这和数据本身是否重复无关——哪怕是完全不同的数据，只要被删除，压缩都会清理其旧版本。
• 若要减少重复活跃数据的存储占用，需要从业务层面优化（比如复用ConfigMap、精简对象定义），etcd的压缩机制无法解决这类问题。

内容的提问来源于stack exchange，提问作者jayunit100