2. etcd 版本演进概览：从 v3.3 到 v3.5 的关键变化

etcd 作为 Kubernetes 控制平面的核心数据存储，其版本演进直接决定了集群的容量上限、运维复杂度与故障恢复能力。从 v3.3 到 v3.5，etcd 在存储引擎、压缩机制、并发控制与资源隔离方面进行了多次重大重构。本章聚焦与容量调优直接相关的特性变化，帮助 SRE 在版本升级时做出正确的容量规划决策。

2.1 版本演进时间线与核心主题

2.2 关键变化一：存储引擎与事务限制

etcd v3.3 使用 boltdb/bolt 作为底层存储引擎，单次事务最大支持 1.5 MiB 的请求体。当 K8s 集群中单个 Secret 或 ConfigMap 超过此阈值时，写入会直接失败。v3.4 开始，etcd 团队将 boltdb 分支为 bbolt，并逐步解除了硬编码限制。

• v3.3：--max-request-bytes=1572864（1.5 MiB），不可动态调整。
• v3.4：引入 --max-request-bytes 启动参数，允许调大至 10 MiB，但需配合后端压缩策略。
• v3.5：bbolt 引擎支持 页面级空闲列表重用，大幅减少后端碎片；--max-request-bytes 默认提升至 3.5 MiB，且支持运行时热加载。

2.3 关键变化二：后端压缩与碎片整理

etcd 的存储空间膨胀主要来自历史版本残留与后端碎片。不同版本在压缩（compact）与碎片整理（defrag）上的能力差异显著。

2.4 关键变化三：并发控制与 Watch 容量

K8s 控制面依赖大量 Watch 连接监听资源变化。etcd v3.3 的 Watch 实现存在 线性读瓶颈，当集群节点数超过 5000 时，Watch 响应延迟会急剧上升。v3.4 引入了 并发读事务（Concurrent Read Transaction），将 Watch 与读请求分离。v3.5 进一步优化了 Watch 存储结构，支持 百万级 Watch 连接。

• v3.3：单节点 Watch 上限约 10 万，超过后出现连接超时。
• v3.4：并发读事务使 Watch 容量提升至 30 万，且延迟稳定在 10ms 以内。
• v3.5：引入 Watch 进度通知（Progress Notification），减少因网络抖动导致的全量重新同步，Watch 容量可达 100 万+。

2.5 版本差异对 K8s 容量调优的影响

以下 SVG 图展示了从 v3.3 到 v3.5 的存储架构演进，重点突出与容量调优相关的组件变化：

2.6 版本升级对容量调优的实践建议

1. v3.3 → v3.4：升级后立即启用 --experimental-compact-hash-check-enabled，并将 --auto-compaction-retention 调整为 1h 以控制历史版本膨胀。
2. v3.4 → v3.5：升级前检查 --quota-backend-bytes 是否 ≥ 8 GiB；升级后确认自动 defrag 已启用（默认开启），并监控 etcd_server_defrag_duration_seconds 指标。
3. 跨版本升级：建议从 v3.3 直接升级至 v3.5，跳过 v3.4 中间版本，以减少存储格式变更带来的兼容性风险。

2.7 版本差异校验的核心思路

在 K8s 平台进行容量调优时，版本差异校验的核心在于：确认当前 etcd 版本是否支持目标容量特性。以下表格总结了三个版本在容量调优关键指标上的差异：