手把手教你用 Velero 实现 K8s 备份恢复与迁移

生产事故不可怕，可怕的是没有备份：用 Velero 拯救 K8s 集群

上个月我们灰度部署时误删了一个 Namespace，3 个 Deployment 和一堆 PV 数据瞬间消失。应用无状态重搭很快，但数据库快照丢了两小时增量数据，被运维老哥念叨了一整周。

用 Kubernetes 的开发者都经历过这种「手滑」或「存储故障」带来的焦虑。今天带你搞定一个运维利器——Velero，CNCF 沙箱项目，专门做 K8s 集群资源的备份、恢复和跨集群迁移。掌握这套工具，能帮你构建可靠的云原生数据保护体系。

前置条件

开始前确认满足以下条件。拥有可控的 K8s 集群是基础，本文基于 1.31+ 版本验证，1.23+ 均可正常运行。kubectl 与集群管理员权限确保你能部署组件并操作核心资源。对象存储后端用于存放备份数据，MinIO 开箱即用，Docker 一行命令即可启动，AWS S3 与阿里云 OSS 等公有云方案同样兼容。本地安装 Velero CLI 后，才能通过命令行触发备份恢复流程。

第一步：安装 Velero CLI

Velero 分为集群内服务端与本地命令行客户端。先搞定客户端。

macOS：

brew install velero

Linux：

wget https://github.com/vmware-tanzu/velero/releases/download/v1.18.0/velero-v1.18.0-linux-amd64.tar.gz
tar -zxvf velero-v1.18.0-linux-amd64.tar.gz
sudo mv velero /usr/local/bin/

验证安装：

velero version

看到 Client 版本号即表示客户端就绪。

第二步：准备对象存储后端（以 MinIO 为例）

Velero 本身不存数据，它将 K8s 资源快照与 PV 数据打包上传到对象存储。对象存储提供高可用、低成本的持久化存储层，是备份体系的关键基础设施。

docker run -d \
  --name minio \
  -p 9000:9000 -p 9001:9001 \
  -e "MINIO_ROOT_USER=admin" \
  -e "MINIO_ROOT_PASSWORD=password123" \
  quay.io/minio/minio server /data

浏览器打开 http://localhost:9001，用 admin/password123 登录，创建 velero-backups Bucket。记录以下参数：

第三步：在 K8s 集群中安装 Velero Server

将 Velero server 部署进集群，同时配置对象存储地址。使用 CLI 一步到位：

velero install \
  --provider aws \
  --bucket velero-backups \
  --secret-file ./credentials-velero \
  --use-volume-snapshots=false \
  --backup-location-config region=minio,s3ForcePathStyle="true",s3Url=http://minio:9000

参数详解：

• --provider aws：Velero 底层使用 AWS S3 SDK，兼容所有 S3 协议对象存储，MinIO、阿里云 OSS 均走此通道
• --secret-file：指向凭据文件，格式如下：

aws_access_key_id = admin
aws_secret_access_key = password123

• --use-volume-snapshots=false：本地 MinIO 无 CSI Snapshot 能力，暂时关闭。生产环境对接云盘时可开启
• s3ForcePathStyle=true：MinIO 需使用路径风格访问，S3 兼容存储常见踩坑点

检查 Velero 状态：

kubectl -n velero get pods

看到 velero-xxx Pod 处于 Running 状态表示服务端就绪。Velero server 以 Deployment 形式常驻集群，通过插件机制对接不同云存储与 CSI 驱动，属于 sidecar-free 设计，无需为每个应用注入代理容器，运维负担显著降低。

第四步：创建第一次备份

对 default 命名空间做完整备份：

velero backup create demo-backup --include-namespaces default

该命令执行流程：

1. 枚举 default 下所有 K8s 资源（Deployment、Service、ConfigMap、Secret 等）
2. 若存在 PV，通过 Restic/Kopia 或 CSI 快照打包实际数据
3. 打包为 tarball 上传至 MinIO 的 velero-backups bucket

查询备份状态：

velero backup describe demo-backup --details

显示 Phase: Completed 即完成。备份完成后，可在 MinIO 控制台查看上传的备份文件，验证数据完整性。

实战：模拟灾难并恢复

删除 default 命名空间模拟故障：

kubectl delete namespace default

等待命名空间彻底删除后，执行恢复：

velero restore create --from-backup demo-backup

恢复流程从对象存储拉回快照，按依赖顺序重建 K8s 资源。watch 进度：

velero restore describe demo-backup-xxx --details

恢复完成后验证：

kubectl -n default get all

Deployment、Pod、Service 全部恢复，PV 挂载数据完整无损。Velero 恢复会分析资源依赖关系，按正确顺序创建资源，并处理 ClusterRoleBinding 等集群级资源冲突，这才是它能真正在生产环境兜底的原因。传统 kubectl apply 无法处理这种复杂的依赖编排，Velero 内置的依赖图算法确保了恢复过程的幂等性。

设置定时备份策略

生产环境必须配置自动备份。Velero 使用 schedule 抽象定时任务，支持 cron 语法：

velero schedule create daily-backup \
  --schedule="0 2 * * *" \
  --include-namespaces default,production \
  --ttl 168h

每天凌晨 2 点备份 default 与 production 命名空间，备份数据保留 7 天（168 小时），到期自动清理。TTL 机制防止对象存储无限膨胀，符合企业数据保留合规要求。

常见问题与踩坑提醒

1. PV 数据备份失败：Velero 默认不备份 PV 数据，需启用 Restic/Kopia 或 CSI Snapshot。备份前检查 velero backup describe 的 Volumes 部分。
2. 对象存储签名错误：使用阿里云 OSS / 腾讯云 COS 时，确保 s3ForcePathStyle 与 region 配置与云厂商文档一致。此类问题多出于 URL 风格配置错误。
3. 恢复时资源冲突：目标集群存在同名资源时，Velero 会跳过恢复。添加 --restore-volumes=true 参数确认 PV 恢复策略。
4. 大集群备份慢：超 500 节点集群建议用 --snapshot-volumes=false 关闭快照，分层备份核心命名空间。

跨集群迁移（进阶）

Velero 的杀手级功能是迁移。在另一个集群部署 Velero Server，指向同一 Bucket，执行 restore 即可。可将应用从测试环境迁移至生产，或从自建集群迁至云端，全程无需修改 Docker 镜像与配置。迁移过程中，Velero 会自动转换集群特定的资源标识，确保目标集群的 Service IP、Ingress 域名等配置正确适配。这种能力在多云容灾、集群升级替换场景中尤为实用。

总结

完整走一遍 Velero 生命周期：安装 → 手动备份 → 定时备份 → 灾难恢复。整个过程不超过 30 分钟，关键时刻能省掉数小时到数天的排障时间。

进阶建议：

• 在开发集群上实操一遍，接 MinIO 练手
• 尝试 velero backup create 的 --selector 标签过滤，按业务维度备份
• 生产环境接入 Prometheus + AlertManager，监控备份失败告警，设置 PagerDuty 或钉钉机器人通知
• 定期执行恢复演练，验证备份有效性，避免「备份成功但恢复失败」的黑洞场景

现在就去创建你的第一个 Schedule，把备份策略纳入日常运维流程。