1. 课程导论：etcd 在云原生架构中的核心地位、灾备 RPO 概念、本课程目标与案例背景
1.1 etcd：云原生控制面的“状态中枢”
在 Kubernetes 生态中，etcd 是唯一保存集群全部元数据与资源状态的分布式键值存储系统。它不仅是控制平面的“大脑”，更是整个集群一致性与可用性的基石。一旦 etcd 数据损坏或丢失，整个 Kubernetes 集群将陷入“失忆”状态，无法调度、无法恢复、无法管理。
| 维度 | etcd 承载的关键数据 | 故障影响 |
|---|---|---|
| 资源对象 | Pod、Service、Deployment、ConfigMap、Secret 等 | 集群无法感知期望状态，调度与编排失效 |
| 集群元数据 | 节点信息、RBAC 规则、CRD 定义、Namespace | 身份认证、权限控制、自定义资源全部不可用 |
| 控制器状态 | Leader 选举、控制器进度、Watch 事件序列 | 控制器循环中断，自动修复与扩缩容停止 |
| 网络与存储绑定 | Service 端点、PV/PVC 绑定、Ingress 路由 | 服务发现中断，持久化存储无法挂载 |
核心认知：etcd 的可用性直接决定了 Kubernetes 控制面的可用性。在灾备场景中，etcd 的恢复速度（RTO）和数据丢失量（RPO）是衡量集群韧性的关键指标。
1.2 灾备 RPO 概念：从“能恢复”到“恢复多少”
灾备领域有两个核心指标：RPO（Recovery Point Objective，恢复点目标）和RTO（Recovery Time Objective，恢复时间目标）。本课程聚焦 RPO 优化，即：当灾难发生时，最多能容忍丢失多少时间窗口内的数据？
- RPO = 0：零数据丢失，需要同步复制或实时备份，成本最高。
- RPO = 5 分钟：允许丢失最近 5 分钟的数据变更，通常通过定期快照实现。
- RPO = 1 小时：允许丢失 1 小时数据，适用于非关键业务。
在 etcd 场景中，RPO 优化面临一个特殊矛盾：备份频率越高，数据丢失越少，但备份操作对 etcd 性能（尤其是缓存命中率）的冲击越大。这正是本课程要解决的核心工程问题。
工程视角：传统 etcd 备份方案（如 etcdctl snapshot save）在集群规模较大时，会触发大量磁盘 I/O 和内存压力，导致缓存热数据被逐出，进而引发 API Server 响应延迟飙升。RPO 优化不能以牺牲缓存命中率为代价。
1.3 本课程目标与案例背景
本课程以一个真实的金融级 Kubernetes 集群灾备优化项目为蓝本，系统讲解如何在不影响 etcd 缓存命中率的前提下，将 RPO 从 30 分钟压缩至 1 分钟以内。
| 维度 | 优化前 | 优化目标 |
|---|---|---|
| 备份策略 | 全量快照，每 30 分钟一次 | 增量 + 全量混合，分钟级 RPO |
| 缓存命中率 | 备份期间从 98% 骤降至 72% | 备份期间不低于 95% |
| 备份耗时 | 单次全量备份 12 分钟 | 增量备份 < 30 秒，全量备份 < 3 分钟 |
| 恢复验证 | 无自动化验证 | 备份后自动校验数据一致性 |
通过本课程，你将掌握：
- etcd 内部存储引擎（boltdb）与缓存机制（mvcc 缓存 + 读缓存）的工作原理。
- 备份操作对缓存命中率影响的量化分析方法。
- 基于 etcd 增量快照 + 预读缓存预热 的 RPO 优化方案设计与实现。
- 生产级灾备自动化流水线的搭建与验证。
重要提示：本课程所有方案均基于 etcd v3.5+ 版本，并已在生产环境（单集群 500+ 节点，etcd 数据量 8GB+）验证。如果你正在维护老旧版本（v3.4 以下），部分特性（如增量快照、并发读取优化）可能不适用，请先完成版本升级。