当 Kubernetes 集群规模上来后，最容易被忽视却最致命的就是备份与灾难恢复。Velero 是 CNCF 毕业级的云原生备份工具，能对整个命名空间乃至持久卷做定时快照、跨集群迁移和一键恢复。本文用实战视角讲清 Velero 的安装、备份、恢复与迁移，帮你把 K8s 数据安全真正落地。
一、为什么 K8s 备份不能只靠 etcd 快照
很多团队的”备份”还停留在定时拷 etcd 数据。但 etcd 快照是集群级的、不可细粒度筛选，恢复时往往要整机回滚，且无法单独搬运某个命名空间到新集群。Velero 的核心价值在于：以资源对象 + 持久卷为粒度，支持按命名空间、标签、资源类型选择性备份，并能跨云、跨集群恢复与迁移。
如果你的集群已经跑起了 Kubernetes Pod/Deployment/Service 这些基础工作负载，下一步就该把备份体系补上——Velero 正是为这件事而生的。
二、Velero 核心概念速览
动手前先理清四个关键对象，后面所有命令都围绕它们展开：
- Backup：一次备份任务，记录选中的 K8s 资源与卷快照。
- BackupStorageLocation（BSL）：备份文件存放的对象存储位置（如 S3、阿里云 OSS、MinIO）。
- VolumeSnapshotLocation（VSL）：持久卷快照的存储位置，通常对接云厂商 CSI 快照能力。
- Schedule / Restore：定时备份计划，以及从备份还原的动作。
三、安装 Velero 与配置对象存储
Velero 由一个服务端（velero 命名空间下的 Deployment + node-agent）和本地 CLI 组成。最常用的是官方 CLI 安装方式，下面以兼容 S3 协议的对象存储为例。
3.1 准备存储凭证文件
先把对象存储的 AK/SK 写进凭证文件，Velero 会把它以 Secret 形式挂载到服务端：
[default]
aws_access_key_id=AKIAxxxxxxxxxxxxxxxx
aws_secret_access_key=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
3.2 执行安装命令
用 velero install 指定 provider、存储桶与区域，CLI 会自动创建 Deployment、node-agent 和 BSL 资源：
velero install \
--provider aws \
--bucket velero-backups \
--secret-file ./credentials-velero \
--backup-location-config region=oss-cn-hangzhou,s3ForcePathStyle=true,endpoint=oss-cn-hangzhou.aliyuncs.com \
--snapshot-location-config region=oss-cn-hangzhou \
--use-node-agent \
--uploader-type restic
安装完成后用 kubectl get pods -n velero 确认两个核心 Pod 处于 Running。如果你对集群存储卷本身还不熟，建议先读完 K8s 持久化存储：PV/PVC 与 StorageClass，理解卷的生命周期后再配置卷快照。
四、备份：资源 + 持久卷
Velero 的备份分两层：K8s 资源对象（Deployment、ConfigMap、Secret 等）默认全量收集；持久卷则通过 Restic 或 CSI 快照单独处理。下面是一个最常见的按命名空间备份：
# 备份 prod 命名空间，并连同 PV 一起用 restic 备份
velero backup create backup-prod-001 \
--include-namespaces prod \
--default-volumes-to-restic \
--snapshot-volumes=true
# 查看备份状态
velero backup get
velero backup describe backup-prod-001 --details
Restic 与 CSI 快照怎么选？ Restic（现已演进为 Kopia 后端）是 Velero 内置的文件级卷备份，兼容任意后端存储、不依赖云厂商快照能力，适合自建集群；CSI 快照则利用云盘原生快照，速度快、一致性好，但需要底层存储支持 CSI Snapshot。生产环境优先用 CSI 快照，混合云或自建集群用 Restic 兜底。
4.1 用 CSI 快照替代 Restic
# 创建使用 CSI 快照的备份（需集群已部署卷快照 CRD 与 CSI 驱动）
velero backup create backup-prod-csi-001 \
--include-namespaces prod \
--snapshot-volumes=true \
--default-volumes-to-csi=true
4.2 选择性备份：标签与资源筛选
真实环境很少需要”全备”，更多是按业务筛选。Velero 提供三类筛选：--include-resources 指定只备份某些资源类型，--exclude-resources 排除 Secrets 等敏感对象，--selector 则基于 Kubernetes 标签只备份打了特定标签的工作负载。这样既缩小备份体积，也避免把不该外泄的密钥带进对象存储。
# 只备份打了 backup=day 标签的 Pod 与 PVC，排除 Secret
velero backup create selective-001 \
--include-resources pods,pvc \
--selector backup=day \
--exclude-resources secrets
配合 --ttl 设置备份保留期，过期备份会被 Velero 自动清理，避免对象存储被历史快照无限膨胀。这也是把备份纳入日常运维纪律的关键一步。
五、定时备份 Schedule
手动备份只适合演练，真实环境必须用 Schedule 定频执行。Velero 的 schedule 语法兼容 Cron：
# 每天凌晨 2 点备份 prod，保留 30 天
velero schedule create daily-prod \
--include-namespaces prod \
--default-volumes-to-restic \
--schedule="0 2 * * *" \
--ttl 720h
# 查看定时任务与生成的备份
velero schedule get
velero backup get
把备份当作 CI 的一环也很自然：在变更前用 GitHub Actions 触发一次带时间戳的 Velero 备份，再执行发布，出问题即可回滚到发布前快照。
六、恢复 Restore：灾难发生时的救命绳
恢复是备份的终极目的。Velero 支持整备恢复、部分恢复、恢复到新命名空间（避免覆盖）：
# 从备份完整恢复到原命名空间
velero restore create restore-001 --from-backup backup-prod-001
# 恢复到新命名空间（迁移/演练常用）
velero restore create restore-002 \
--from-backup backup-prod-001 \
--namespace-mappings prod:prod-recover
# 查看恢复进度
velero restore get
velero restore describe restore-001
恢复失败最常见的原因是原备份里包含了集群独有的节点亲和、PV 绑定等约束。Velero 提供 --restore-volumes 与资源筛选参数，必要时用 --exclude-resources 跳过冲突对象。
七、跨集群迁移：Velero 的高光场景
Velero 真正的”杀手锏”是集群迁移：把 A 集群的命名空间连同数据整体搬到 B 集群，常用于机房下线、云厂商切换、多集群灰度。做法是在目标集群装好 Velero 并指向同一个对象存储桶，然后直接恢复：
# 目标集群：配置相同 BSL 后，直接基于源集群备份恢复
velero restore create migrate-prod \
--from-backup backup-prod-001 \
--namespace-mappings prod:prod
由于备份文件与快照都在对象存储里，迁移不需要两个集群网络互通，只要都能访问同一存储即可，这比手动导出 YAML + 拷数据稳妥得多。
八、Velero 方案对比与落地检查清单
下表把三种常见备份思路放在一起对比，帮助你向团队解释为什么选 Velero：
| 方案 | 粒度 | 跨集群 | 持久卷 | 运维成本 |
|---|---|---|---|---|
| etcd 快照 | 集群级 | 难 | 整盘 | 低 |
| 手动导出 YAML | 资源级 | 可 | 不支持 | 高 |
| Velero | 资源+卷级 | 原生支持 | Restic/CSI | 中 |
生产落地前，对照这张检查清单逐条确认：
| 检查项 | 是否完成 |
|---|---|
| 对象存储桶已创建且 Velero 可写 | ☐ |
| velero 命名空间 Pod 全部 Running | ☐ |
| 关键命名空间已配置 Schedule 定时备份 | ☐ |
| 持久卷备份方式（Restic/CSI）已验证 | ☐ |
| 至少做过一次真实 Restore 演练 | ☐ |
| 备份保留期 TTL 已按合规设定 | ☐ |
九、常见排错
1. 备份卡在 InProgress。 多半是 node-agent 没起来或无法访问对象存储。先看 velero backup logs backup-xxx，再查 velero 与 node-agent Pod 日志里的 endpoint/凭证错误。
2. 卷未被备份。 确认加了 --default-volumes-to-restic 或 CSI 快照配置，且目标 PVC 没有被 volumePolicy 排除。
3. 恢复后服务起不来。 通常是原集群专属的节点选择、StorageClass 名称在目标集群不存在。用 --namespace-mappings 配合资源替换，或在恢复后手动修正。
十、小结与落地建议
Velero 把 K8s 备份从”玄学”变成可编排、可验证的工程动作。建议先从非核心命名空间做每日 Schedule 备份，跑通一次完整 Restore 演练后再覆盖生产。当你的 Docker 与容器编排 体系逐渐云原生化，Velero 应当作为标配底座，而不是事故后的补救措施。
