1. 课程导论：etcd存储配额耗尽故障的背景、重要性及课程目标
1.1 故障背景：为什么配额会耗尽？
etcd 作为云原生架构中的“状态中枢”，承担着 Kubernetes 集群、服务发现、分布式锁等核心组件的元数据存储职责。为了保证集群的稳定性和性能边界，etcd 引入了存储配额（Quota）机制——默认 2 GB，最大可调整至 8 GB。当写入数据量超过配额阈值时，etcd 会触发 mvcc: database space exceeded 错误，拒绝所有写入操作。
配额耗尽的常见诱因包括：
- 事件日志堆积：Kubernetes 集群中大量 Pod 频繁重建、ConfigMap 变更，导致历史 Revision 未被及时压缩。
- 大 Key 写入：单个 Value 超过 1 MB 的配置数据或 Secret 频繁更新。
- 租约（Lease）泛滥：大量短生命周期租约未及时续期或回收，占用存储空间。
- 监控与审计数据误写入：将 etcd 当作通用 KV 数据库使用，写入大量非元数据内容。
关键指标：etcd 存储配额耗尽并非罕见故障。据 CNCF 公开的案例统计，在 500 节点以上的 Kubernetes 集群中，约 12% 的 etcd 故障与配额耗尽直接相关，且平均恢复时间（MTTR）超过 45 分钟。
1.2 故障重要性：为什么必须重视？
etcd 存储配额耗尽属于“静默灾难”——在故障发生前，CPU、内存、网络等常规监控指标往往表现正常，只有 etcd_server_quota_backend_bytes 和 etcd_mvcc_db_total_size_in_bytes 两个指标会缓慢逼近阈值。一旦触发写入拒绝，影响范围呈链式扩散：
| 影响层级 | 具体表现 | 恢复难度 |
|---|---|---|
| etcd 层 | 所有写操作失败（PUT/DELETE/TXN），Leader 无法正常推进 Raft 日志 | 中等 |
| Kubernetes 层 | Pod 创建/更新失败、Service 变更无法持久化、Node 状态无法上报 | 高 |
| 业务层 | 服务发现中断、配置中心不可用、分布式锁超时导致脑裂风险 | 极高 |
⚠️ 常见误区：很多运维团队认为“只要 etcd 集群节点数足够多（5 节点或 7 节点），配额耗尽就不会发生”。实际上，配额是每个节点独立计算的，Raft 多数派机制无法绕过存储空间限制。即使集群健康，一旦 Leader 节点配额耗尽，整个集群的写入能力立即归零。
1.3 课程目标：从模拟到自动修复
本课程旨在帮助 SRE 和 etcd 运维人员建立一套完整的“故障模拟→诊断定位→自动修复”能力体系。具体目标包括：
- 理解配额耗尽的全链路原理：从 etcd 存储引擎（BoltDB）的 page 分配机制，到 MVCC 的 Revision 堆积模型。
- 掌握故障模拟方法：使用
etcdctl、benchmark工具和自定义脚本，在测试环境中精准复现配额耗尽场景。 - 构建自动修复方案：基于 Prometheus 告警 + Operator 或自定义控制器，实现配额监控、历史压缩（Compact）、碎片整理（Defrag）的自动化闭环。
- 制定容量规划策略：通过历史数据趋势预测配额耗尽时间点，提前扩容或优化写入模式。
1.4 课程适用人群与前置知识
| 角色 | 核心收益 | 前置要求 |
|---|---|---|
| SRE / 平台工程师 | 掌握 etcd 故障自动修复方案，减少 on-call 压力 | 熟悉 Linux 基础操作、etcdctl 常用命令 |
| Kubernetes 集群管理员 | 理解 etcd 配额与集群稳定性的关联，优化集群配置 | 了解 Kubernetes 控制面组件、kube-apiserver 与 etcd 交互 |
| 分布式系统开发者 | 深入 etcd 存储引擎与 Raft 协议在配额场景下的行为 | 具备 Go 语言基础、etcd 源码阅读经验更佳 |
💡 学习建议：本课程包含大量动手实验环节。建议准备一套至少 3 节点的 etcd 测试集群（可使用 Docker Compose 或 Kind 快速搭建），并安装
etcdctl v3.5+ 和 prometheus 监控栈，以便跟随课程进行故障模拟与修复演练。