使用Velero备份还原K8S的数据
一 原理
Velero 的基本原理就是将Kubernetes 集群资源对象数据备份到对象存储中，并能从对象存储中拉取备份数据来恢复集群资源对象数据。不同于etcd 备份——将集群的全部资源备份起来——Velero 是对Kubernetes 集群内资源对象级别进行备份，可以通过对Type、Namespace、Label等对象进行分类备份或者恢复。
elero的操作（backup, scheduled backup, restore）都是CRD自定义资源，存储etcd中。 Velero的整体模块架构如下图1，首先，客户端是一个简单的交互客户端Velero-cli，封装了各种命令参数，可以执行安装、配置、备份、恢复等操作。服务端则可以类比成一个典型的kubebuild 的operator，首先是不同的CR，也就是API。中间Controller 层需要用到一些相对比较独立的服务时，都会通过插件系统来对接到内部或者外部的插件服务。底层的数据拷贝层是对接Restic。其它都是外部的插件实现，http://velero.io/plugins 就代表内部的插件实现，由Velero 或者第三方厂商来实现。
按需备份（On-demand backups）
backup： 将复制的Kubernetes 资源对象上传到对象存储中，且可选择调用云环境提供的API 来创建持久化卷快照，以及可选择指定在备份期间执行backup hook操作（比如：可能需要在快照之前告诉数据库将其内存中的缓存刷新到磁盘）。 Tips： backup操作并不是严格的原子性备份，在备份期间，若是有Kubernetes 资源对象被新建或编辑操作，则这个操作变动可能不会被包含在backup备份中。 指令： velero backup create test-backup 流程：
- Velero客户端向Kubernetes API server 发起创建Backup对象的请求
- BackupController 检测到新建Backup对象，并进行参数验证
- BackupController 开始备份执行过程。通过与API server交互，获取需要备份的资源数据
- BackupController 向对象存储服务（如：AWS S3）发起上传备份数据请求
- 默认情况，backup操作是会对持久卷（PV）进行磁盘快照备份的，不过是可以通过–snapshot-volumes=false进行取消
图2 Velero 备份流程
备份还原（Restores）
restore： 对历史备份的Kubernetes 资源对象和持久卷进行还原，且允许按需选择指定部分资源对象还原到指定命名空间（Namespace）中。且可以选择在备份还原期间或还原后执行restore hook操作（比如：执行自定义数据库的还原操作之后，再执行数据库应用容器启动动作）。 Tips： 默认情况下，Velero进行的是非破坏性还原操作（non-destructive restore），这意味着它不会删除目标集群上的任何数据——即如果备份中的资源对象已经存在于目标集群中，restore操作将会跳过该资源的还原。当然，也可通配置更新策略(–existing-resource-policy=update)，尝试更新目标集群中已存在资源，以匹配备份中的资源数据。 指令： velero restore create 流程：
- Velero客户端向Kubernetes API server 发起创建Restore对象的请求
- RestoreController 检测到新建Restore 对象，并进行参数验证
- RestoreController 从对象存储服务处获取待还原备份资源数据信息，并进行备份资源还原前的一些预处理工作（比如：备份资源的API versions版本验证）
- RestoreController 开始备份还原执行过程，一次性还原所有指定待还原资源
定时备份（Scheduled backups）
schedule： 可以定期备份数据。在schedule 创建后，便创建第一次备份，随后备份将按照指定调度周期（由 Cron 表达式指定）进行备份。定时备份保存的名称为 -，其中 格式为 YYYYMMDDhhmmss。
API versions
Velero备份资源时，使用Kubernetes API 首选版本为每个组（group）/资源（CRD）备份。而还原备份的目标集群中，必须存在相同API 组（group）/资源（CRD）版本。需要注意的是：只是需要存在，而并不是需要首选版本。例如，如果正在备份的集群在 things API 组中有一个 gizmos 资源，group/versions为 things/v1alpha1、things/v1beta1 和 things/v1，并且服务器的首选group/versions 是 things/v1，那么所有 gizmos 将从 things/v1 API 端点备份。 当从该集群恢复备份时，目标集群必须具有 things/v1 端点才能恢复 Gizmo。
使用docker 安装minio对象存储
docker run -p 9000:9000 -p 9090:9090 --name minio -d --restart=always \
-e "MINIO_ACCESS_KEY=admin" -e "MINIO_SECRET_KEY=admin12345" \
-v /home/minio/data:/data minio/minio server /data \
--console-address ":9090" --address ":9000"
登录minio，创建buckets
在k8s master 安装 velero 客户端
先决条件: Kubernetes 集群 v1.16 或更高版本
wget https://mirror.ghproxy.com/https://github.com/vmware-tanzu/velero/releases/download/v1.10.3/velero-v1.10.3-linux-amd64.tar.gz
tar -zxvf velero-v1.10.3-linux-amd64.tar.gz
cp velero-v1.10.3-linux-amd64/velero /usr/local/bin/
创建velero 使用minio的密钥
[root@master1 ~]# cat credentials-velero [default] aws_access_key_id = admin aws_secret_access_key = admin12345
在k8s中安装 velero服务器端
velero install --provider aws --plugins velero/velero-plugin-for-aws:v1.2.1 \
--bucket data --secret-file /root/credentials-velero \
--use-volume-snapshots=false --backup-location-config \
region=minio,s3ForcePathStyle="true",s3Url=http://172.20.106.193:9000
- 这里使用 MinIO 作为对象存储，MinIO 是兼容 S3 的，所以配置的 provider（声明使用的 Velero 插件类型）是 AWS，
- –secret-file 用来提供访问 MinIO 的密钥
- –use-restic 表示使用开源免费备份工具 restic 备份和还原持久卷数据，启用该参数后会部署一个名为 restic 的 DaemonSet 对象
- –plugins 使用的 velero 插件，本文使用 AWS S3 兼容插件。
- s3Url 配置MinIO 服务对外暴露的nodePort端口及部署节点IP
- 需要注意的是启动需要修改Restic DaemonSet spec 配置，调整为实际环境中Kubernetes 指定pod 保存路径的hostPath
备份k8s test 命名空间
[root@master1 ~]# kubectl get pod -n test NAME READY STATUS RESTARTS AGE apache-7d57797d98-cv44s 1/1 Running 1 (28m ago) 7d23h nginx-8f458dc5b-hv2np 1/1 Running 1 (28m ago) 7d23h
备份
velero backup create backup-test --include-namespaces test -n velero
删除test命名空间，并且恢复
kubectl delete ns test #恢复 velero restore create --from-backup backup-test --wait
参考：
https://blog.csdn.net/qq_14910065/article/details/130081105
