上一篇【第81篇】K8s集群升级实战——从v1.24到v1.29的平滑升级别把生产搞挂下一篇【第83篇】K8s性能调优——大规模集群的那些优化秘籍摘要上篇讲了升级升级翻车是最常见的灾难之一。但灾难不止升级——误删namespace、etcd磁盘损坏、机房断电、勒索软件……没有备份这些都是灭顶之灾。K8s的备份分两个层次etcd快照备份集群所有状态恢复回到某个时刻见第061篇和Velero备份K8s资源定义PV数据支持跨集群迁移、按namespace/label筛选恢复。这篇文章给你一套定期备份策略以及一次完整的模拟灾难恢复演练——毕竟不演练的备份等于没备份。一、两种备份层次1.1 区别【etcd快照 vs Velero】 etcd快照: • 备份: 整个etcd的所有key(所有资源) • 恢复: 整个集群回到快照时刻(全量) • 粒度: 整个集群(不能只恢复某个ns) • 速度: 快(一个文件) • 适合: 集群级灾难恢复、升级前保命 Velero: • 备份: K8s资源(YAML) 可选PV数据 • 恢复: 可按ns/label筛选恢复部分资源 • 粒度: 细(能只恢复某个namespace) • 速度: 慢(逐个资源) • 适合: 跨集群迁移、误删恢复、定期备份维度etcd快照Velero备份单位整个集群namespace/资源级能否部分恢复❌✅能否跨集群同集群(新etcd)✅ 任意集群是否含PV数据✅(etcd里)可选(需插件)操作复杂度低中要点两者互补——etcd快照是全量保命符升级前必做Velero是精细手术刀误删某ns可只恢复那个ns、还能跨云迁移。生产环境建议两者都做定时etcd快照防全集群灾难定时Velero防误删和做迁移。二、etcd快照复习实操2.1 已经是老朋友# 备份(第061篇讲过, 这里强调自动化)ETCDCTL_API3etcdctl snapshot save /backup/etcd-$(date%F-%H%M).db\--endpointshttps://127.0.0.1:2379\--cacert/etc/kubernetes/pki/etcd/ca.crt\--cert/etc/kubernetes/pki/etcd/server.crt\--key/etc/kubernetes/pki/etcd/server.key# 验证ETCDCTL_API3etcdctl snapshot status /backup/etcd-*.db-wtable# 定时任务(CronJob或系统cron)# 0 2 * * * /usr/local/bin/etcd-backup.sh # 每天凌晨2点# 并同步到远程存储(S3/OSS), 别只留本地!要点etcd快照必须自动化异地存储。只存在本机磁盘等于没备份——etcd磁盘坏了备份也跟着坏。用CronJob或系统cron每天跑同步到对象存储S3/MinIO/OSS。保留策略每天1份、保留7天、每周1份、保留4周。三、Velero实战3.1 安装与备份# 1. 安装Velero(连对象存储)veleroinstall\--provideraws\--bucketk8s-backups\--secret-file ./credentials-aws\--use-volume-snapshotstrue\--backup-location-configregioncn-north-1# 2. 备份整个prod namespacevelero backup create prod-backup --include-namespaces prod# 3. 定时备份(每天凌晨3点)velero schedule create daily-prod\--include-namespaces prod\--schedule0 3 * * *# 4. 看备份velero backup get# NAME STATUS CREATED EXPIRES# prod-backup Completed 2026-07-28 03:00:00 0000 UTC 720h3.2 恢复# 误删了prod? 恢复它!kubectl delete namespace prod# 灾难发生!velero restore create --from-backup prod-backup# 几分钟后prod namespace满血回来 ✅# 跨集群迁移(在另一个集群)velero backup get# 备份在对象存储, 新集群也能看到velero restore create --from-backup prod-backup --namespace-mappings prod:prod-new四、完整灾难恢复演练4.1 模拟恢复【一次完整的灾难恢复演练流程】 场景: 升级v1.29翻车, etcd数据损坏, 集群不可用 恢复步骤: 1. 确认有升级前的etcd快照 (异地存储) 2. 重建/修复控制平面节点 3. 停掉所有apiserver(防止写冲突) 4. etcdctl snapshot restore 恢复数据 5. 重启etcd apiserver 6. 验证: kubectl get pods -A 看到所有资源回来 7. 如果部分资源丢失 → 用Velero补恢复特定ns 8. 验证业务: 访问服务, 确认OK ⚠️ 关键: 这套流程要定期演练! 很多人从没试过恢复, 真出事发现快照是坏的# 演练检查清单□ 备份文件存在且可访问(异地)□ etcdctl snapshot status 显示正常(未截断)□ restore 后能 kubectl get 到资源 □ 业务服务能正常响应 □ 恢复时间(RTO)在可接受范围 □ 数据丢失量(RPO)符合预期五、备份策略建议5.1 一套能直接用的方案【生产备份方案(推荐)】 层次1 - etcd快照(全量保命): • 频率: 每天1次 升级前手动1次 • 保留: 7天每日 4周每周 • 存储: 异地对象存储(S3/MinIO) • 演练: 每季度恢复演练1次 层次2 - Velero(精细恢复): • 频率: 每天1次(生产ns) • 范围: 资源YAML PV数据(关键业务) • 保留: 14天 • 用途: 误删恢复、跨集群迁移 层次3 - 应用数据(数据库等): • 数据库自带备份(如mysqldump/PG basebackup) • 独立于K8s(数据库有自己节奏) • 注意: PV快照不能替代数据库逻辑备份!要点三层备份各管一段——etcd快照管集群全量状态、Velero管K8s资源卷数据、数据库逻辑备份管应用数据。特别警告PV快照块级别不能替代数据库逻辑备份mysqldump——因为块快照可能捕获到事务进行到一半的不一致状态恢复出来数据库损坏。数据库一定要有自己的逻辑备份。本篇小结K8s备份分两层互补etcd快照全量保命恢复回到某时刻升级前必做要自动化异地和Velero精细恢复可按ns/label筛选还能跨集群迁移。两者都做最稳。关键纪律不演练的备份等于没备份——定期做模拟灾难恢复确认快照未截断、恢复后业务正常。数据库必须单独做逻辑备份PV快照抓不到一致的事务状态。RTO恢复时间和RPO数据丢失量是衡量备份方案的两个核心指标。下篇讲性能调优——大规模集群的优化秘籍。上一篇【第81篇】K8s集群升级实战——从v1.24到v1.29的平滑升级别把生产搞挂下一篇【第83篇】K8s性能调优——大规模集群的那些优化秘籍