Kubernetes 可复现故障场景为何强调恢复验证

Kubernetes 容灾里最容易被误判的一刻，是所有状态都变绿：备份任务显示完成，GitOps 已同步，StatefulSet 已滚动，Pod 也进入 Running 和 Ready。可如果数据库里没有预期记录、入口流量没有切到恢复集群，或者两块卷恢复到了不同时间点，业务仍然没有回来。可复现故障场景之所以强调恢复验证，就是要把“工具执行成功”改写成“用户可用、数据正确、时间达标”的证据链。

CNCF 可复现灾备场景：https://www.cncf.io/blog/2026/09/10/kubernetes-disaster-recovery-guidance-from-three-reproducible-failure-scenarios/

Kubernetes etcd 运维文档：https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/

VolumeGroupSnapshot GA 说明：https://kubernetes.io/blog/2026/05/08/kubernetes-v1-36-volume-group-snapshot-ga/

把可恢复性当成一种需要验证的架构能力

“可恢复性模式”的核心并不复杂：先定义一个可重复制造的故障，再准备确定的输入和预期结果，最后在独立目标中完成恢复并核对业务断言。它与普通备份检查最大的区别，是验收点放在恢复链路末端，而不是某个工具自己的状态字段上。

可复现很重要，因为灾备问题往往发生在工具之间的接缝。备份系统负责保存对象和卷数据，Git 保存声明，基础设施代码建立目标集群，DNS、负载均衡和身份系统恢复访问路径。每个组件都可能单独成功，组合起来却仍缺一段。固定工作负载、固定故障、固定断言之后，团队才能判断到底是哪一个接缝没有接上。

真正要验证的是四个边界能否重新接起来

第一层是声明状态，例如 Deployment、StatefulSet、Service、ConfigMap 和权限对象；第二层是存储状态，包括数据库文件、日志和卷内容；第三层是可承载恢复的目标环境，它需要先具备集群、节点、网络、存储类和必要控制器；第四层才是用户路径，包括入口、身份、依赖服务和真实请求。

这四层不能彼此代替。GitOps 可以完美重建 YAML，却可能自动创建一块全新的空卷；备份工具可以恢复卷，却不会凭空建立目标集群；Pod Ready 只能证明就绪探针通过，也不能证明业务数据、登录或关键查询正确。恢复验证的工作，就是为每一层设置可观察结果，并在最终业务断言里把它们合并。

三个可复现场景分别戳破三种假成功

备份完成不等于卷数据可恢复

第一种假成功是只看备份任务的 Completed。这个状态通常说明备份流程结束，却不自动证明持久卷字节已经进入外部存储，更不证明数据库恢复后能读到预期内容。更可靠的检查至少包含两层：先核对卷数据确实被搬运，再删除测试命名空间，在干净目标中恢复并查询一组已知记录。

声明恢复不等于存储状态恢复

第二种假成功发生在 GitOps。控制器根据仓库重新创建 StatefulSet 和 PVC 后，资源可以全部变绿，但新 PVC 里的数据库可能是空的。这里没有任何组件“出错”，只是 Git 保存的是意图，备份保存的是状态。演练必须故意把两者拆开，再验证恢复顺序是否会误建空卷、覆盖已有资源或遗漏存储映射。

每块卷成功不等于应用整体一致

第三种假成功来自多卷应用。两块卷分别快照时都可能 ReadyToUse，但它们对应的时间点并不一致。订单卷与支付卷只要相差几秒，就可能出现支付记录找不到订单的破坏性组合。Kubernetes v1.36 中 VolumeGroupSnapshot 已进入 GA，可以由一个组快照请求协调多块卷；不过支持仍取决于 CSI 驱动，而且 crash-consistent 也不等于数据库已经完成应用级刷盘或静默。正确做法仍是用业务不变量验证恢复结果。

一场合格演练要留下哪些证据

可以先从一个最小实验开始。准备一套有明确内容的有状态应用，例如固定四条记录和一个可查询接口；恢复目标必须是从未运行过该应用的干净集群；备份存储要位于独立故障域；演练脚本要记录故障开始、恢复动作、数据通过、入口通过四个时间点。

随后定义三组断言。资源断言检查对象是否齐全、控制器是否就绪；数据断言检查行数、关键键值、跨卷引用或检查点是否一致；用户路径断言从真实入口发起请求，确认 DNS、证书、身份、服务发现和下游依赖都能工作。RPO 由恢复数据点与故障时刻的差距决定，RTO 则应覆盖发现、决策、恢复、流量切换和验证，而不只是工具执行耗时。

只做备份监控会留下哪些架构后果

最常见的反例，是把“每天备份成功率 100%”当成灾备完成度。它会鼓励团队优化备份任务，却不暴露存储类映射、跨集群权限、镜像可用性、外部依赖、数据一致性和流量切换问题。另一个反例是只删除 Pod；这只能验证控制器调谐和副本重建，无法覆盖集群级故障与数据恢复。

可复现演练也有成本：需要隔离目标、准备脱敏样本、维护断言、控制故障注入权限，并避免演练流量误入生产。但这些成本换来的不是一份演示，而是一组可以回归的恢复契约。版本升级、存储迁移、拓扑变化或备份工具替换之后，同一场景可以再次执行，直接比较恢复时间和失败位置。

上线前用这份清单做判断

• 恢复目标是否在灾难发生前就有明确的创建与接管责任？
• 声明状态和持久数据是否分别有来源，并规定了不会误建空卷的恢复顺序？
• 备份检查是否包含真实卷数据，而不只读取任务状态？
• 多卷应用是否定义了跨卷不变量，并核实 CSI 驱动的组快照能力？
• 演练是否在干净目标中恢复完整应用，而不是只重建一个 Pod？
• 验收是否同时覆盖资源、数据和用户路径，并记录端到端 RPO、RTO？
• 每次平台、存储或权限变更后，是否能用同一场景重新回归？

当这些问题都有可重复的答案时，备份才从“存在”变成“可用”。Kubernetes 能帮助系统重新调谐，但灾备是否成立，最终仍要由恢复后的数据、用户路径和时间目标共同证明。