1. 灾备场景概述：什么是 Kubernetes 灾备、为什么需要灾备、灾备的 RTO 与 RPO 目标
1.1 什么是 Kubernetes 灾备
Kubernetes 灾备（Disaster Recovery, DR）是指在集群或应用遭遇故障、数据损坏、区域中断或人为误操作时，能够将关键工作负载及其数据恢复到可用状态的一系列策略、流程与技术手段。与传统的单机或虚拟化灾备不同，K8s 灾备需要覆盖控制平面、工作负载声明（Deployment/StatefulSet）、配置（ConfigMap/Secret）、持久化数据（PV/PVC）以及集群自身的元数据。
核心原则：K8s 灾备不是简单的“备份 YAML”，而是对“应用状态 + 数据状态 + 集群拓扑”的三维保护。
1.2 为什么需要灾备
生产环境中的 Kubernetes 集群面临多种风险，灾备是保障业务连续性的最后一道防线。以下列出最常见的四类风险场景：
| 风险类别 | 典型场景 | 影响范围 |
|---|---|---|
| 基础设施故障 | 云厂商可用区宕机、物理机磁盘损坏、网络分区 | 整个集群或节点池不可用 |
| 软件与配置错误 | 错误的 Deployment 镜像、资源限制配置导致 OOM、QoS 降级 | 部分 Pod 或命名空间异常 |
| 数据损坏与误操作 | 误删 PVC、ConfigMap 被覆盖、数据库数据损坏 | 有状态服务数据丢失 |
| 安全攻击 | 勒索软件加密持久卷、恶意删除命名空间 | 全集群数据与配置受损 |
注意：本课程聚焦于 Deployment 工作负载在灾备场景下的镜像拉取策略、资源限制配置与 QoS 保障。这些是灾备恢复中最容易被忽视但直接影响 RTO 的关键环节。
1.3 灾备的核心目标：RTO 与 RPO
任何灾备方案都必须用两个量化指标来衡量其有效性：
- RTO（Recovery Time Objective，恢复时间目标）：从灾难发生到业务完全恢复所允许的最大时间间隔。例如 RTO=15 分钟，意味着必须在 15 分钟内让应用重新对外提供服务。
- RPO（Recovery Point Objective，恢复点目标）：灾难发生时允许丢失的最大数据量（通常以时间衡量）。例如 RPO=5 分钟，意味着最多丢失最近 5 分钟写入的数据。
在 Kubernetes 环境中，RTO 和 RPO 的达成与以下因素强相关：
| 影响因素 | 对 RTO 的影响 | 对 RPO 的影响 |
|---|---|---|
| 镜像拉取速度 | 大镜像从远端仓库拉取可能耗时数分钟 | 无直接影响 |
| 资源限制与 QoS | 资源不足导致 Pod 无法调度或频繁 OOMKill | 间接影响（Pod 重启可能导致数据丢失） |
| 持久化数据备份频率 | 无直接影响 | 决定 RPO 上限 |
| 集群元数据备份 | 影响控制平面恢复速度 | 无直接影响 |
实战建议：在制定灾备方案时，先确定业务可接受的 RTO/RPO 阈值，再反向推导镜像缓存策略、资源预留比例和数据备份周期。不要追求“零丢失”，而是追求“可承受的丢失”。
1.4 灾备场景下的关键挑战（SVG 图）
下图展示了 Deployment 灾备恢复过程中，镜像拉取、资源限制与 QoS 配置三个核心环节的交互关系与潜在瓶颈：
1.5 本课程在灾备体系中的定位
本课程不覆盖完整的集群级灾备方案（如 Velero、etcd 备份、跨集群联邦），而是聚焦于 Deployment 工作负载在灾备恢复过程中最容易被忽视的三个技术细节：
- 镜像拉取策略与加速：如何通过 ImagePullPolicy、镜像预热、本地缓存等手段缩短 Pod 启动时间，直接降低 RTO。
- 资源限制的合理配置：requests/limits 的设置如何影响调度成功率与 Pod 稳定性，避免恢复时因资源不足而失败。
- QoS 等级与驱逐优先级：Guaranteed、Burstable、BestEffort 三类 QoS 在节点资源紧张时的行为差异，以及如何为关键业务选择正确的 QoS 等级。
课程收益：学完本章后，你将能够为 Deployment 制定一份“灾备就绪”的镜像、资源与 QoS 配置清单，使恢复时的 RTO 缩短 30%~60%，同时降低因资源争抢导致的二次故障概率。