Kubernetes-Velero集群备份还原和迁移

1.Velero 简介

1.1.Velero介绍

Velero (西班牙语，意思是“帆船)最初由 Heptio 公司开发，项目名称为 “Heptio Ark”。Heptio 由 Kubernetes 的两位联合创始人 Craig McLuckie 和 Joe Beda 创立，旨在为 Kubernetes 用户提供一系 列可靠的工具来增强集群的管理、运维能力。Ark 项目应运而生，其核心目标就是解决 Kubernetes 集 群的备份和恢复这一关键需求，当时市场上缺乏功能完善且易于使用的针对 Kubernetes 的此类工具。

Heptio 在 2017 年将 Ark 开源发布，开源之后，吸引了大量 Kubernetes 用户以及开发者的关注。许多 企业和开发者开始尝试使用 Ark 来保障自身集群内应用及数据的安全性，同时也积极向项目贡献代码、 反馈使用过程中遇到的问题以及提出新的功能需求，社区围绕 Ark 开始逐渐活跃起来，不断推动其功能 的完善和对更多存储、云平台环境等的适配。

2018 年，随着 Heptio 被 VMware 收购，Ark 项目为了更好地体现其通用性以及适应更广泛的社区发展 需要，被重命名为 “Velero”。后由 VMware Tanzu 对其进行维护和开发， 并于 2018 年捐赠给 CNCF， 成为 CNCF 的孵化项目之一。

发展至今，Velero 已经成为 Kubernetes 云原生生态中不可或缺的一部分，众多企业将其作为保障集群 业务连续性、进行数据保护和应用迁移的重要手段。其社区仍然保持着较高的活跃度，不断有开发者贡 献新的功能特性、改进文档，而且与其他云原生相关项目之间也有着紧密的协作关系，一起助力云原生 应用在 Kubernetes 平台上更安全、稳定地运行。

Velero是一个云原生的灾难恢复和迁移工具，它本身也是开源的, 采用 Go 语言编写，可以安全的备份、 恢复和迁移Kubernetes集群资源和持久卷。

特点

• 备份可以按集群资源的子集，按命名空间、资源类型标签选择器进行过滤，从而为备份和恢复的内 容提供高度的灵活性

• 支持复制当前 Kubernetes 集群的资源到其它 Kubernetes 集群,注意:只备份kubernetes中的元数 据,不会备份PVC等数据内容

• 通过聚合 API 服务器公开的资源可以轻松备份和恢复，即使它们存储在单独的 etcd 数据库中

官网: https://velero.io/

Github 地址：https://github.com/vmware-tanzu/velero

官方文档：https://velero.io/docs/

1.2.Velero 主要功能

备份功能

• 集群资源备份：能够备份 Kubernetes 集群中的各种资源对象，包括 Deployment、Service、 ConfigMap、Secret、PersistentVolumeClaims 等几乎所有常见资源类型。例如，可以定期备份 重要的应用部署配置以及相关的服务定义等，方便在需要时进行还原。

• 持久卷数据备份：除了资源对象本身，Velero 还支持对与应用相关联的持久卷（Persistent Volumes）中的数据进行备份。这对于保存有重要业务数据（如数据库文件、用户上传文件等）的 应用来说至关重要，确保数据不会因意外删除、集群故障等情况丢失。 可基于文件系统备份(FileSystem Backup)备份Pod卷中的数据，并借助于restc或kopia上传到对象 存储系统 支持基于快照备份PV，这种方式较之FSB能确保文件的一致性;它支持两种操作: 1 仅创建PV快照,2 创建PV快照，并借助于restic或kopia上传到对象存储系统上

恢复功能

• 资源还原：可以将之前备份的资源对象按照备份时的状态准确地还原到集群中，无论是因为误操作 删除了某个关键服务，还是集群整体出现故障重建后，都能快速恢复应用部署和配置。

• 数据恢复：与资源还原配合，能把持久卷中的数据也恢复到相应的存储位置，使整个应用恢复到备 份时刻的可用状态，保障业务的连续性。

灾难恢复与迁移支持

• 跨集群迁移：方便将应用及数据从一个 Kubernetes 集群迁移到另一个集群，比如从测试环境集群 迁移到生产环境集群，或者在进行数据中心迁移、云平台更换等场景下，实现平滑的资源和数据转 移。

• 灾难恢复预案：作为灾难恢复计划的关键部分，通过定期备份，在遇到如集群硬件故障、数据中心 灾难等极端情况时，能快速依据备份在新的环境中恢复集群的关键业务应用，最大限度减少业务停 机时间和损失

1.3.Velero 使用场景

灾备场景： 提供备份和恢复kubernetes集群的能力

迁移场景： 提供复制和迁移集群资源到其他集群的能力，可用于快速实现开发,测试,生产等不同集群配置同步 需要将两个集群连接同一个对象存储服务

1.4.Velero 与 ETCD 备份比较

• ETCD 备份是直接把集群的全部资源备份，而 Velero 可以支持对 Kubernetes 集群内对象级别进行 备份。

• Velero 除了对 Kubernetes 集群进行整体备份外， 还可以支持对 Namespace、Type、Label、 Pod 等对象进行分类备份或者恢复

• ETCD方式是直接对ETCD的数据库备份,无需连接API Server, 而 velero是通过API Server 进行备份, 要求Kubernetes 是可用的才可以还原 Velero 自身支持实现周期的定期备份,ETCD需要自行通过其它方式实现

• Velero 还支持将PV卷的数据进行备份,ETCD方式只能备份Kubernetes 集群的资源

1.5.Velero 组件

Velero 组件一共分三部分，分别是客户端和服务端,插件。

客户端：

运行在本地的 velero命令行工具，包括安装服务端、备份、定时任务备份、恢复等命令，特别需要 注意的是，安装服务端时需要在机器上已配置好kubectl及集群kubeconfig。

服务端：

就是一组运行在Kubernetes集群中（以Pod方式运行）controller 资源 通过一组 CRD 实现的 Operator，包括： Backup Controller 和 Restore Contoller 这是整个工具的核心控制组件，负责与 Kubernetes API 服务器通信，协调备份和恢复任务的执 行，管理备份记录等，同时也会和各种插件交互来完成具体的功能，比如和存储插件协作进行数据 的存储和读取操作。

插件（Plugins）：

https://velero.io/docs/main/supported-providers/

存储插件：用于对接不同的存储后端，支持多种存储类型，像 Amazon S3、Google Cloud Storage、Azure Blob Storage、MinIO等云存储服务，以及一些本地的兼容 S3 协议的存储系 统，如MinIO，实现备份数据的可靠存储和获取。

卷快照插件：针对不同的存储提供商（如不同云平台对持久卷的管理机制不同），卷快照插件 能够与相应的存储系统集成，实现对持久卷数据的快照创建和恢复，提高备份和恢复的效率， 尤其是对于大容量数据的处理。

1.6.Velero 后端存储

Velero 支持两种关于后端存储的 CRD ，分别是 BackupStorageLocation 和 VolumeSnapshotLocation 。

BackupStorageLocation 主要用来定义 Kubernetes 集群资源的数据存放位置，也就是集群对象数据，不是 PVC 的数据。 主要支持的后端存储是 S3 兼容的存储，比如：MinIO，阿里云 OSS，AWS S3，Azure Blob，Google Cloud 等。

VolumeSnapshotLocation 主要用来给 PV 做快照，这个需要使用 CSI 等存储机制。 如果是公有云需要云提供商提供插件。比如: 阿里云已经提供了插件， 也可以使用专门的备份工具 Restic ，把 PV 数据备份到阿里云 OSS 中去(安装时需要自定义选项)。

1.7.Velero 备份还原的工作流程

备份数据： 本地velero客户端发送备份命令，就会调用API Server创建Backup资源对象 服务端的Backup Controller 收到通知有新的Backup对象创建并执行验证 服务端的Backup Controller 开始执行备份过程，向API Server查询需要备份的数据服务端的Backup Controller 调用OSS对象存储服务，将备份数据保存到对象对象存储上 默认情况下，BackupController还会为PV创建Snapshot(若PV支持)，用户可使用 –snapshotvolumes=false 选项禁用该功能 Velero 会与 Kubernetes API 服务器交互，首先获取要备份的资源对象的清单信息，然后根据配置 决定是否对关联的持久卷数据进行备份（通过调用相应的存储插件来操作）。对于持久卷数据备 份，它会协调存储系统（如支持的云存储服务或本地存储解决方案）创建数据的快照或者复制数据 到指定的备份存储位置。整个备份过程中会生成相应的备份记录，记录备份的资源范围、时间、状 态等关键信息。

恢复数据： 本地velero客户端发送恢复指令，就会调用API Server创建Restore资源对象 服务端的Restore Controller 收到通知有新的Restore对象创建并执行验证 服务端的Restore Controller 调用对象存储，将指定的备份文件下载下来 服务端的Restore Controller 开始执行恢复过程，根据备份数据调用API Server重新创建相关资源 对象 当执行恢复操作时，Velero 读取备份记录，先将资源对象的定义重新应用到 Kubernetes 集群中， 创建相应的资源（如重新创建 Deployment 来启动应用副本等）。对于有持久卷数据需要恢复的情 况，它会从备份存储位置获取数据并还原到对应的持久卷中，确保应用能够正常使用之前的数据。

2.安装和使用 Velero Cli

2.1.Velero CLI 二进制安装

软件包下载地址：

https://github.com/vmware-tanzu/velero/releases

k8s版本要求：

wget https://github.com/vmware-tanzu/velero/releases/download/v1.17.2/velero-v1.17.2-linux-amd64.tar.gz
tar -zxf velero-v1.17.2-linux-amd64.tar.gz
cp velero-v1.17.2-linux-amd64/velero /usr/local/bin/

minio创建Access Key并配置权限

创建并记录 Access Key 和 Secret key

aws_access_key_id = tksm4QnaHeL0VkS7946h
aws_secret_access_key = dnMQ2n6d3eRMmdoqBzurNk3GwnFTpmJMBzmrveSZ

在K8s集群的Master节点上MinIO的创建认证文件

cat > credentials-velero <<EOF
[default]
aws_access_key_id = tksm4QnaHeL0VkS7946h
aws_secret_access_key = dnMQ2n6d3eRMmdoqBzurNk3GwnFTpmJMBzmrveSZ
EOF

2.2.安装Velero Server

velero install \\
–provider aws \\
–image swr.cn-north-4.myhuaweicloud.com/ddn-k8s/docker.io/velero/velero:v1.16.2 \\
–plugins swr.cn-north-4.myhuaweicloud.com/ddn-k8s/docker.io/velero/velero-plugin-for-aws:v1.12.0 \\
–backup-location-config region=minio,s3ForcePathStyle="true",s3Url=http://minio.apotos.com:9000 \\
–bucket velero \\
–secret-file ./credentials-velero \\
–namespace velero \\
–use-node-agent \\
–use-volume-snapshots=false \\
–wait

命令参数详解

这条 velero install 命令，目的是在 Kubernetes 集群中部署 Velero 备份恢复工具，并配置使用一个兼容 S3 协议的存储后端（通常指 MinIO 或 AWS S3）。以下是各参数的具体作用：

执行前的关键检查点

运行此命令前，必须确认以下几点，否则安装会失败：

2.3.执行备份命令

velero backup create k8s-backup-$TIME –kubeconfig ~/.kube/config –include-namespaces=default

命令参数详解

• 作用：Velero 的子命令，用于创建一个新的备份

• 说明：这是执行备份操作的主要命令

• 作用：备份的名称

• 说明：$TIME 是一个变量，通常会被替换为当前时间戳，使备份名称唯一

• 示例：如果 $TIME=20250225-1430，则备份名为 k8s-backup-20250225-1430

• 作用：指定 Kubernetes 集群的连接配置文件

• 路径：~/.kube/config 是默认的 kubeconfig 文件位置

• 说明：Velero 需要连接 Kubernetes API Server 来备份资源

• 作用：指定要备份的命名空间

• 值：default 表示只备份 default 命名空间中的资源

• 说明：如果不指定，默认会备份所有命名空间

2.4.查看备份状态

velero backup describe k8s-backup-2026-02-25-15-53-10
velero backup logs k8s-backup-2026-02-25-15-53-10
root@master01:~# velero backup describe k8s-backup-2026-02-25-15-53-10
Name:         k8s-backup-2026-02-25-15-53-10
Namespace:   velero
Labels:       velero.io/storage-location=default
Annotations: velero.io/resource-timeout=10m0s
            velero.io/source-cluster-k8s-gitversion=v1.32.11
            velero.io/source-cluster-k8s-major-version=1
            velero.io/source-cluster-k8s-minor-version=32
​
Phase: Completed
​
​
Namespaces:
Included: default
Excluded: <none>
​
Resources:
Included cluster-scoped:   <none>
Excluded cluster-scoped:   <none>
Included namespace-scoped: *
Excluded namespace-scoped: <none>
​
Label selector: <none>
​
Or label selector: <none>
​
Storage Location: default
​
Velero-Native Snapshot PVs:   auto
File System Backup (Default): false
Snapshot Move Data:           false
Data Mover:                   velero
​
TTL: 720h0m0s
​
CSISnapshotTimeout:   10m0s
ItemOperationTimeout: 4h0m0s
​
Hooks: <none>
​
Backup Format Version: 1.1.0
​
Started:   2026-02-25 16:09:30 +0800 CST
Completed: 2026-02-25 16:09:31 +0800 CST
​
Expiration: 2026-03-27 16:09:30 +0800 CST
​
Total items to be backed up: 22
Items backed up:             22
​
Backup Volumes:
Velero-Native Snapshots: <none included>
​
CSI Snapshots: <none included>
​
Pod Volume Backups: <none included>
​
HooksAttempted: 0
HooksFailed:     0

MinIO 查看备份

定时备份

#Examples :
#Create a backup every 6 hours.
velero create schedule NAME –schedule="0 */6 * * *”
# Create a backup every 6 hours with the @every notation.
velero create schedule NAME –schedule="@every 6h"
#Create a daily backup of the web namespace.
velero create schedule NAME –schedule="@every 24h" –include-namespaces web
# Create a weekly backup, each living for 90 days(2160 hours).
velero create schedule NAME –schedule="@every 168h" –ttl 2160h@m0s

2.5.恢复资源

先删除部分资源

root@master01:~# kubectl get pod -n default
NAME                     READY   STATUS   RESTARTS       AGE
myweb-7d756bcd87-chbsv   1/1     Running   1 (6h56m ago)   25h
myweb-7d756bcd87-kcbz7   1/1     Running   1 (6h56m ago)   25h
myweb-7d756bcd87-pn27p   1/1     Running   1 (6h56m ago)   25h
network-tools           1/1     Running   1 (6h56m ago)   25h
root@master01:~# kubectl delete deployments.apps myweb
deployment.apps "myweb" deleted
root@master01:~# kubectl get pod -n default
NAME           READY   STATUS   RESTARTS       AGE
network-tools   1/1     Running   1 (6h56m ago)   25h

恢复前查看备份名称

root@master01:~# velero backup get
NAME                             STATUS     ERRORS   WARNINGS   CREATED                         EXPIRES   STORAGE LOCATION   SELECTOR
k8s-backup-2026-02-25-15-53-10   Completed   0       0         2026-02-25 16:09:30 +0800 CST   29d       default           <none>
k8s-backup-2026-02-25-16-00-37   Completed   0       0         2026-02-25 16:00:37 +0800 CST   29d       default           <none>

在worker节点上可以提前下载相关镜像

docker pull swr.cn-north-4.myhuaweicloud.com/ddn-k8s/docker.io/velero/velero-restore-helper:v1.15.2

在master节点执行恢复命令

#使用如下命令恢复指定的备份
velero restore create –from-backup k8s-backup-2026-02-25-15-53-10 –wait
root@master01:~# velero restore create –from-backup k8s-backup-2026-02-25-15-53-10 –wait
Restore request "k8s-backup-2026-02-25-15-53-10-20260225165431" submitted successfully.
Waiting for restore to complete. You may safely press ctrl-c to stop waiting – your restore will continue in the background.
​
Restore completed with status: Completed. You may check for more information using the commands `velero restore describe k8s-backup-2026-02-25-15-53-10-20260225165431` and `velero restore logs k8s-backup-2026-02-25-15-53-10-20260225165431`.

2.6.检查恢复的资源

创建restores资源

root@master01:~# kubectl get restores.velero.io -A
NAMESPACE   NAME                                           AGE
velero     k8s-backup-2026-02-25-15-53-10-20260225165431   14m

完成恢复后，会在MinIO存储中同时创建和一个和backups同级的restores的目录

查看恢复情况

root@master01:~# velero restore get
NAME                                           BACKUP                           STATUS     STARTED                         COMPLETED                       ERRORS   WARNINGS   CREATED                         SELECTOR
k8s-backup-2026-02-25-15-53-10-20260225165431   k8s-backup-2026-02-25-15-53-10   Completed   2026-02-25 16:54:31 +0800 CST   2026-02-25 16:54:32 +0800 CST   0       12         2026-02-25 16:54:31 +0800 CST   <none>

查看详细信息

root@master01:~# velero restore describe k8s-backup-2026-02-25-15-53-10-20260225165431 –details
Name:         k8s-backup-2026-02-25-15-53-10-20260225165431
Namespace:   velero
Labels:       <none>
Annotations: <none>
​
Phase:                       Completed
Total items to be restored: 21
Items restored:             21
​
Started:   2026-02-25 16:54:31 +0800 CST
Completed: 2026-02-25 16:54:32 +0800 CST
​
Warnings:
Velero:     <none>
Cluster:   <none>
Namespaces:
  default: could not restore, Pod:network-tools already exists. Warning: the in-cluster version is different than the backed-up version
            could not restore, Endpoints:myweb-clusterip already exists. Warning: the in-cluster version is different than the backed-up version
            could not restore, Endpoints:myweb-loadbalancer already exists. Warning: the in-cluster version is different than the backed-up version
            could not restore, Endpoints:myweb-nodeport already exists. Warning: the in-cluster version is different than the backed-up version
            could not restore, Service:baidu already exists. Warning: the in-cluster version is different than the backed-up version
            could not restore, Service:kubernetes already exists. Warning: the in-cluster version is different than the backed-up version
            could not restore, Service:myweb-clusterip already exists. Warning: the in-cluster version is different than the backed-up version
            could not restore, Service:myweb-loadbalancer already exists. Warning: the in-cluster version is different than the backed-up version
            could not restore, Service:myweb-nodeport already exists. Warning: the in-cluster version is different than the backed-up version
            could not restore, EndpointSlice:myweb-clusterip-qmd4s already exists. Warning: the in-cluster version is different than the backed-up version
            could not restore, EndpointSlice:myweb-loadbalancer-vst84 already exists. Warning: the in-cluster version is different than the backed-up version
            could not restore, EndpointSlice:myweb-nodeport-smp7h already exists. Warning: the in-cluster version is different than the backed-up version
​
Backup: k8s-backup-2026-02-25-15-53-10
​
Namespaces:
Included: all namespaces found in the backup
Excluded: <none>
​
Resources:
Included:       *
Excluded:       nodes, events, events.events.k8s.io, backups.velero.io, restores.velero.io, resticrepositories.velero.io, csinodes.storage.k8s.io, volumeattachments.storage.k8s.io, backuprepositories.velero.io
Cluster-scoped: auto
​
Namespace mappings: <none>
​
Label selector: <none>
​
Or label selector: <none>
​
Restore PVs: auto
​
CSI Snapshot Restores: <none included>
​
Existing Resource Policy:   <none>
ItemOperationTimeout:       4h0m0s
​
Preserve Service NodePorts: auto
​
Uploader config:
​
​
HooksAttempted:   0
HooksFailed:     0
​
Resource List:
apps/v1/Deployment:
  – default/myweb(created)
apps/v1/ReplicaSet:
  – default/myweb-7d756bcd87(created)
discovery.k8s.io/v1/EndpointSlice:
  – default/kubernetes(skipped)
  – default/myweb-clusterip-qmd4s(failed)
  – default/myweb-loadbalancer-vst84(failed)
  – default/myweb-nodeport-smp7h(failed)
v1/ConfigMap:
  – default/kube-root-ca.crt(skipped)
v1/Endpoints:
  – default/kubernetes(skipped)
  – default/myweb-clusterip(failed)
  – default/myweb-loadbalancer(failed)
  – default/myweb-nodeport(failed)
v1/Pod:
  – default/myweb-7d756bcd87-chbsv(created)
  – default/myweb-7d756bcd87-kcbz7(created)
  – default/myweb-7d756bcd87-pn27p(created)
  – default/network-tools(failed)
v1/Service:
  – default/baidu(failed)
  – default/kubernetes(failed)
  – default/myweb-clusterip(failed)
  – default/myweb-loadbalancer(failed)
  – default/myweb-nodeport(failed)
v1/ServiceAccount:
  – default/default(skipped)
​

检查刚才的删除的资源是否恢复

root@master01:~# kubectl get deployments.apps
NAME   READY   UP-TO-DATE   AVAILABLE   AGE
myweb   3/3     3           3           56s
root@master01:~# kubectl get pod -n default
NAME                     READY   STATUS   RESTARTS       AGE
myweb-7d756bcd87-chbsv   1/1     Running   0             63s
myweb-7d756bcd87-kcbz7   1/1     Running   0             62s
myweb-7d756bcd87-pn27p   1/1     Running   0             62s
network-tools           1/1     Running   1 (7h1m ago)   25h

恢复完成