Kubernetes备份恢复、集群迁移与灾备演练

Kubernetes 对象可声明、Pod可重建,并不等于业务已经备份。真正可恢复的系统至少包含集群资源、持久卷数据、数据库一致性、镜像与安装包、外部依赖配置、密钥及恢复步骤。备份成功只是起点,只有在隔离环境恢复并通过业务验收,才算具备恢复能力。

本文以 Velero、CSI快照、文件级备份和etcd快照为主要工具,重点说明它们的边界、组合方式和演练方法。存储插件、云平台和应用一致性能力差异较大,实施前应依据当前版本官方文档验证。

一、先定义恢复目标

每个业务先回答:

  • RPO:最多允许丢失多长时间的数据;
  • RTO:从宣布灾难到恢复服务最多允许多久;
  • 恢复范围:单对象、单命名空间、单应用、单集群或跨区域;
  • 依赖顺序:身份、网络、存储、数据库、中间件、应用和入口;
  • 数据一致性:崩溃一致、文件系统一致还是应用一致;
  • 责任人和宣布灾难、切换、回切的审批者。

RPO为15分钟不代表每15分钟拍一次快照就一定达标,还要考虑失败、复制延迟和校验。RTO必须包含基础设施准备、数据传输、DNS/流量切换和业务验证。

二、建立备份对象矩阵

对象 常见方法 关键风险
Kubernetes API对象 Velero或导出清单 CRD、版本和生成资源顺序
etcd 原生快照 主要用于控制面级恢复,非应用级选择恢复
CSI卷 VolumeSnapshot 快照可能与源卷处于同一故障域
文件卷 节点代理/文件级备份 大文件、权限、稀疏文件和恢复时长
数据库 原生备份、日志归档 事务一致性和时间点恢复
镜像与Chart 仓库复制和离线保留 标签漂移、签名和依赖缺失
Secret和证书 加密备份或外部密钥系统 泄露、过期和目标环境不可用
外部资源 IaC、云快照和清单 DNS、负载均衡、对象存储不在集群内

同一应用通常需要多种备份方式。不要把CSI快照当作独立异地备份,先确认其底层存储位置、保留策略和区域故障边界。

三、Velero的职责与边界

Velero可备份和恢复Kubernetes资源,并通过CSI快照、文件系统备份或提供商插件处理卷数据。备份元数据通常保存在对象存储中。它不会自动保证数据库事务一致,也不会替代etcd控制面灾难恢复。

建议将备份对象存储放在独立账号、区域或安全域,启用版本控制、不可变/保留策略、加密和最小权限。Velero运行身份只拥有所需存储权限,恢复权限与日常备份权限尽量分离。

四、部署前检查

部署前确认:

  • Kubernetes与Velero版本兼容;
  • 对象存储插件和凭据方式受支持;
  • CSI driver支持v1 VolumeSnapshot API;
  • VolumeSnapshotClass标注、删除策略和快照耐久性符合要求;
  • 节点代理能调度到挂载数据卷的节点;
  • 网络、代理、DNS和对象存储带宽足够;
  • CRD和webhook可在目标集群恢复;
  • 备份数据量、窗口、保留期和成本已估算。

安装完成后先做小命名空间测试,而不是立即勾选整个集群。

五、按应用创建可解释的计划

apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: payments-daily
  namespace: velero
spec:
  schedule: "0 2 * * *"
  template:
    includedNamespaces:
    - payments
    labelSelector:
      matchLabels:
        backup-policy: gold
    ttl: 720h0m0s
    snapshotMoveData: true

计划应按业务等级拆分,避免一个超大备份任务同时失败。标签选择器要有资产治理,防止新资源因漏标签而从未备份。记录每个计划的负责人、RPO、存储位置、保留期、加密和恢复Runbook。

六、应用一致性不能靠“同时拍快照”猜测

对于数据库和消息系统,优先使用其原生备份、日志归档或集群复制能力。需要卷快照时,可通过pre/post hook执行冻结、刷盘或进入备份模式,但必须确认命令成功、超时和解冻逻辑。

metadata:
  annotations:
    pre.hook.backup.velero.io/container: database
    pre.hook.backup.velero.io/command: '["/bin/sh","-c","/opt/backup/freeze.sh"]'
    post.hook.backup.velero.io/container: database
    post.hook.backup.velero.io/command: '["/bin/sh","-c","/opt/backup/unfreeze.sh"]'

如果post hook失败,业务可能保持冻结,必须有独立看门狗和告警。多Pod、多卷的一致性边界需要应用架构明确说明,不能因为备份任务显示Completed就假定事务一致。

七、etcd快照解决的是另一类问题

etcd快照适合控制面整体损坏、误删大量对象等集群级恢复,通常将集群还原到某一时间点。它不是日常恢复单个命名空间的便捷工具,也不包含持久卷真实数据、外部负载均衡器或镜像仓库。

自建控制面应按Kubernetes和etcd文档配置定期快照、异地复制、加密与恢复演练。托管集群则确认云厂商控制面备份责任、恢复粒度和工单流程,不要假设一定能获取或恢复etcd快照。

八、恢复前先准备干净环境

恢复计划包含:

  1. 集群版本、API和CRD兼容;
  2. CNI、CSI、Ingress/Gateway、证书和DNS;
  3. 存储类、可用区、卷模式和快照驱动;
  4. 镜像仓库、签名策略和拉取凭据;
  5. 外部数据库、队列、对象存储和密钥系统;
  6. 目标命名空间、ResourceQuota和准入策略;
  7. 业务流量隔离,避免恢复副本连接生产下游。

先恢复CRD和必要控制器,再恢复自定义资源。若GitOps控制器同时运行,可能立即把恢复对象改回Git状态,应在Runbook中定义暂停、忽略或接管方式。

九、一次标准恢复流程

velero backup get
velero backup describe payments-20261021 --details
velero backup logs payments-20261021

velero restore create payments-drill-20261021 \
  --from-backup payments-20261021 \
  --namespace-mappings payments:payments-restore \
  --wait

velero restore describe payments-drill-20261021 --details
velero restore logs payments-drill-20261021

恢复后不要只看资源数量。验证PVC Bound、数据可读、数据库恢复点、应用健康、证书、DNS、网络策略、入口、后台任务和审计。恢复对象已存在时的跳过或更新策略必须提前确认,避免把测试结果误解为“已覆盖”。

十、跨集群迁移要处理环境差异

常见差异:

  • StorageClass和CSI driver名称不同;
  • LoadBalancer、IngressClass、GatewayClass实现不同;
  • 节点标签、可用区和架构不同;
  • 域名、证书、外部IP和防火墙不同;
  • Secret由不同KMS或外部Secret系统管理;
  • CRD、Operator和API版本不一致;
  • 镜像仓库地址和网络出口不同。

将环境差异放入可审阅的转换规则或Git覆盖层,避免恢复后手工批量编辑。对于CSI快照跨集群恢复,必须验证目标集群的驱动兼容性和快照可访问性。

十一、从备份迁移到新集群

推荐顺序:

  1. 用IaC创建目标基础设施;
  2. 安装并验证平台组件;
  3. 同步镜像、Chart、策略和Secret来源;
  4. 恢复非生产副本并完成技术验证;
  5. 预同步大体量数据;
  6. 进入短暂停写或双写/日志追赶阶段;
  7. 执行最终增量和一致性校验;
  8. 小比例切流并观察SLO;
  9. 全量切换,保留明确回切窗口;
  10. 到期后再清理源环境。

迁移不是简单restore。若业务持续写入,必须由数据库复制、日志归档或应用层机制解决切换点一致性。

十二、恢复演练的三级模型

级别一:对象恢复

恢复单个Deployment、ConfigMap或测试PVC,验证工具链与权限。

级别二:应用恢复

在隔离命名空间或临时集群恢复一个完整应用,执行数据和业务验收。

级别三:集群/区域灾难

从独立控制面、对象存储和镜像仓库在另一故障域恢复,演练流量切换、跨团队协作和决策链。

每次演练记录实际RPO/RTO、人工步骤、失败项、数据校验和整改负责人。无法在目标时间内完成的系统应调整架构或承诺,而不是只修改报告。

十三、备份监控与告警

至少监控:

  • 计划是否按时创建任务;
  • 完成、部分失败和失败数量;
  • 最近成功时间与RPO距离;
  • 备份时长、对象数、数据量和吞吐;
  • 快照/DataUpload/DataDownload状态;
  • 对象存储容量、权限、版本和不可变策略;
  • 恢复演练最后成功时间;
  • 证书、插件和凭据到期时间。

“每天任务成功率99%”可能掩盖某个关键命名空间连续失败。告警应按业务备份计划和RPO判断。

十四、安全与勒索防护

  • 备份账户与生产账户分离;
  • 使用不可变对象锁或WORM保留;
  • 加密传输与静态数据,密钥独立托管;
  • 备份身份可写新对象,但限制覆盖和删除;
  • 恢复权限仅在演练或事故窗口临时授予;
  • 对删除备份、修改保留策略和停用计划单独审计;
  • 定期离线或跨账号复制关键恢复集;
  • 恢复前扫描镜像和制品,防止把已入侵状态原样恢复。

十五、常见失败与排查

备份Completed但数据不可用

检查是否只备份了Kubernetes对象、VolumeSnapshot是否真的持久、hook是否成功、应用是否一致。用恢复而不是日志证明。

恢复后PVC一直Pending

核对StorageClass、CSI driver、可用区、访问模式、volumeMode、快照类和配额。跨集群时检查驱动名称和快照句柄是否可访问。

CR恢复失败或字段丢失

先安装兼容CRD与Operator,检查存储版本和转换webhook。不要在目标集群只有旧CRD时强行导入新对象。

恢复后流量误接生产

隔离环境默认禁止外连,使用不同域名、Secret和账号。后台Job、消费者和通知服务恢复后应先保持暂停。

十六、生产验收清单

  • [ ] 每个关键业务都有明确RPO、RTO和恢复负责人;
  • [ ] Kubernetes对象、卷、数据库、镜像和外部依赖均在范围内;
  • [ ] 备份存储与生产故障域、账号和权限分离;
  • [ ] CSI快照耐久性和跨集群可用性已验证;
  • [ ] 数据库使用应用一致性备份或明确接受崩溃一致;
  • [ ] 备份失败按业务RPO告警;
  • [ ] 恢复顺序、GitOps和准入策略冲突有处理方案;
  • [ ] Secret、证书、DNS和流量切换包含在Runbook;
  • [ ] 最近一次隔离恢复达到目标且保留证据;
  • [ ] 删除和勒索场景下仍有不可变恢复集。

十七、官方参考

恢复能力是一条完整的业务链,而不是一个备份按钮。把恢复作为定期交付物,以真实数据、隔离环境和业务验收反复证明,才能让RPO和RTO从文档承诺变成可执行能力。

Copyright © yan-jian.com 2023 - 2026 · Powered by GitBook更新时间: 2026-10-21 09:44:40

results matching ""

    No results matching ""