1. etcd 在 K8s 中的核心角色：集群数据基石
在 Kubernetes 集群架构中，etcd 承担着唯一数据存储的关键角色。所有集群状态——包括 Pod、Service、ConfigMap、Secret、节点信息、RBAC 策略等——都以键值对形式持久化在 etcd 中。这意味着 etcd 的容量与性能直接决定了整个 K8s 集群的稳定性与可用性。
核心结论：etcd 是 K8s 的“大脑”与“记忆体”。一旦 etcd 出现容量瓶颈、性能抖动或数据不一致，整个集群将面临调度失败、API 响应超时、甚至数据丢失的风险。
1.1 etcd 在 K8s 架构中的位置
下图展示了 etcd 与 K8s 控制面各组件的交互关系：
1.2 etcd 存储的关键数据对象
etcd 中存储的数据量级与集群规模、资源数量、变更频率直接相关。以下表格列出主要数据类别及其对容量的影响：
| 数据类别 | 典型键数量级 | 单键平均大小 | 容量影响因子 |
|---|---|---|---|
| Pod 对象 | 10³ ~ 10⁵ | 2 ~ 8 KB | 高（频繁创建/删除产生大量历史版本） |
| ConfigMap / Secret | 10² ~ 10⁴ | 1 ~ 100 KB | 极高（大 ConfigMap 单键可达 1 MB） |
| Service / EndpointSlice | 10² ~ 10⁴ | 1 ~ 20 KB | 中（随 Pod 数量线性增长） |
| Node 对象 | 10¹ ~ 10³ | 3 ~ 10 KB | 低（节点数量相对稳定） |
| CRD 自定义资源 | 10¹ ~ 10⁵ | 1 ~ 50 KB | 高（取决于 CRD 设计和使用方式） |
| 事件（Events） | 10⁴ ~ 10⁶ | 0.5 ~ 2 KB | 极高（大量事件堆积会快速消耗存储） |
容量调优关注点：etcd 默认的存储配额为 2 GB（v3.4+ 可调整）。当数据量接近配额时，etcd 会触发告警并进入只读模式，导致集群无法正常调度和更新。因此，理解各类数据对容量的影响是调优的第一步。
1.3 容量与性能的关联模型
etcd 的容量和性能并非独立指标，它们之间存在紧密的耦合关系：
- 存储配额（--quota-backend-bytes）：限制 etcd 后端数据库文件的最大大小。超过配额会触发告警，集群进入维护模式。
- 历史版本压缩（auto-compaction）：保留指定数量的历史版本（如保留 5 分钟或 1000 个版本）。版本堆积过多会导致存储膨胀和查询性能下降。
- 碎片整理（defragmentation）：压缩操作会产生存储碎片，定期整理可回收空间，提升读写性能。
- 请求延迟（latency）：当 etcd 存储接近配额或存在大量历史版本时，读写延迟会显著增加，进而拖慢 API Server 响应速度。
1.4 版本差异对容量调优的影响
不同 etcd 版本在容量管理、压缩策略、碎片整理行为上存在显著差异。本课程后续章节将重点对比以下版本差异：
| 功能维度 | etcd v3.4 | etcd v3.5 | etcd v3.6（预览） |
|---|---|---|---|
| 默认存储配额 | 2 GB | 2 GB（可调至 8 GB） | 4 GB（推荐 8 GB） |
| 自动压缩模式 | periodic / revision | periodic / revision | 新增基于时间的智能压缩 |
| 碎片整理 | 需手动执行 | 支持在线 defrag（v3.5.0+） | 自动后台 defrag |
| 大键值对支持 | 单键 ≤ 1.5 MB | 单键 ≤ 1.5 MB | 单键 ≤ 10 MB（实验特性） |
| 存储后端 | boltDB v1.3.x | boltDB v1.3.x | bbolt（优化版） |
版本迁移注意事项：在升级 etcd 版本前，必须验证新版本的压缩策略和配额行为是否与现有集群兼容。错误的版本差异理解可能导致数据丢失或集群不可用。本课程将提供详细的版本差异校验清单和操作步骤。
1.5 容量调优的最终目标
通过本课程的学习，你将能够：
- 准确评估当前 etcd 集群的容量使用状况和性能瓶颈
- 根据 K8s 集群规模和工作负载特征，制定合理的容量规划
- 掌握不同 etcd 版本下的压缩、碎片整理和配额调整方法
- 建立版本差异校验流程，确保升级和调优操作的安全可靠
- 通过监控和告警体系，提前发现容量风险并自动响应
etcd 的容量调优不是一次性的配置修改，而是需要持续观察、分析和调整的运维实践。接下来的章节将从版本差异校验入手，逐步深入每个调优细节。