云原生灾备基础：灾备等级定义与架构
灾备（Disaster Recovery, DR）是保障业务连续性的最后一道防线。在云原生环境中，基础设施从物理机/虚拟机转向容器与编排平台，传统的灾备模型需要重新适配。本节从灾备核心指标、经典架构以及云原生带来的新挑战三个维度展开。
2.1 灾备等级核心指标：RPO 与 RTO
任何灾备方案都围绕两个关键指标定义其保护能力：
| 指标 | 全称 | 定义 | 典型值（云原生） | 衡量维度 |
|---|---|---|---|---|
| RPO | Recovery Point Objective | 允许丢失的最大数据量（时间跨度） | 秒级～分钟级 | 数据完整性 |
| RTO | Recovery Time Objective | 从故障发生到服务恢复的最大允许时间 | 分钟级～小时级 | 业务中断时长 |
实践要点：RPO 与 RTO 并非孤立指标。在云原生场景下，RPO 受数据持久化方式（StatefulSet 卷、分布式存储）影响较大；RTO 则受镜像拉取、服务启动依赖、配置注入等环节制约。定义灾备等级时，应同时给出两个指标的约束，并明确“不可接受”的阈值。
2.2 常见灾备架构：主备、双活、多活
根据 RPO/RTO 的严格程度，业界将灾备架构分为三个主流等级。下图展示了三种架构的核心拓扑与切换逻辑。
2.3 云原生环境下的灾备挑战
容器化与编排平台（Kubernetes）改变了应用的部署与运行方式，也给灾备带来了传统架构中不存在的难题。以下列出四个核心挑战：
- 有状态服务的状态一致性
StatefulSet、PVC（PersistentVolumeClaim）与分布式存储（如 Ceph、Longhorn）的备份与恢复，需要保证数据与 Pod 拓扑的强一致性。简单的卷快照可能无法处理多 Pod 间的写入顺序。 - 配置与声明式资源的版本管理
Kubernetes 资源（Deployment、ConfigMap、Secret、CRD）的版本与依赖关系复杂。灾备恢复时，资源创建顺序错误可能导致应用启动失败。 - 网络策略与多集群通信
跨集群/跨区域的灾备切换需要同步网络策略（NetworkPolicy）、Service Mesh 配置、DNS 记录与证书。网络割裂或策略冲突会直接导致恢复后的服务不可达。 - 镜像与制品仓库的可用性
灾备站点必须能够拉取到正确的容器镜像版本。如果镜像仓库本身未做异地同步或镜像被清理，恢复过程将因“镜像拉取失败”而中断。
常见误区：很多团队只备份了 PVC 数据，却忽略了 CRD 实例、Operator 版本、Webhook 配置等“元数据”。在云原生灾备中，数据 + 资源 + 配置三者缺一不可。建议使用 Velero 或 Kasten K10 等工具进行统一备份，并定期执行恢复演练。
2.4 云原生灾备架构参考（双可用区 + 异地备份）
下图展示了一个典型的云原生灾备部署模型：主集群与备集群分别部署在同一区域的不同可用区（AZ），同时将关键数据异步复制到异地对象存储，用于应对区域级故障。
2.5 灾备等级与架构选择对照表
下表汇总了不同业务场景下推荐的灾备等级与对应架构：
| 业务场景 | 推荐 RPO | 推荐 RTO | 推荐架构 | 关键依赖 |
|---|---|---|---|---|
| 开发/测试环境 | 24 小时 | 4 小时 | 主备（异步） | 对象存储 + 定时备份 |
| 内部业务系统（OA/HR） | 1 小时 | 30 分钟 | 主备（同步） | 块存储快照 + 应用级恢复 |
| 核心交易系统 | 秒级 | 5 分钟 | 双活 | 分布式存储 + 多副本 + 自动切换 |
| 全球化互联网服务 | 近零 | 秒级 | 多活 | 全局负载均衡 + 数据分片 + 异地多写 |