Velero 是怎样对 Kubernetes 资源实现备份还原的？

Velero 是怎样对 Kubernetes 资源实现备份还原的-工作原理

每个 Velero 操作——按需备份、定时备份、还原——都是一个自定义资源，用 Kubernetes 自定义资源定义(CRD)定义并存储在 etcd 中。Velero 还包括处理自定义资源以执行备份、还原和所有相关操作的控制器.

可以备份或还原集群中的所有对象，也可以按类型、命名空间和/或标签筛选对象.

Velero 非常适合灾难恢复用例，以及在集群上执行系统操作（如升级）之前快照应用程序状态.

按需 backups

备份操作：

1. 将复制的 Kubernetes 对象的压缩包上传到云对象存储中
2. 调用云提供程序 API 以创建永久性卷的磁盘快照（如果指定）

可以选择指定要在备份期间执行的备份挂钩。例如，可能需要告诉数据库在拍摄快照之前将其内存中的缓冲区刷新到磁盘, 有关 备份挂钩

请注意，群集备份不是严格原子备份。如果在备份时正在创建或编辑 Kubernetes 对象，则它们可能不会包含在备份中, 捕获不一致信息的几率很低

定时备份

计划操作允许以重复的时间间隔备份数据, 可以随时创建定时备份，然后按定时计划的指定时间间隔执行第一次备份。这些间隔由 Cron 表达式指定.

Velero 会保存从日程表中创建的备份，其名称为 <SCHEDULE NAME>-<TIMESTAMP> , 其中 <TIMESTAMP> 的格式为 YYYMMDDhhmmss, 更多信息请参见 备份参考文档

备份工作流程

当运行 velero backup create test-backup 时：

1. Velero 客户端调用 Kubernetes API 服务器来创建一个 Backup 对象
2. BackupController 注意到新的 Backup 对象并进行验证
3. BackupController 开始备份过程。它通过查询 API 服务器的资源来收集要备份的数据
4. BackupController 会调用对象存储服务-例如 AWS S3 -来上传备份文件

默认情况下，velero backup create 会对任何持久化卷进行磁盘快照:

可以通过指定额外的标志来调整快照, 运行 velero backup create --help 来查看可用的标志.

可以通过选项--snapshot-volumes=false 来禁用快照.

image.png

Restore 工作流程

当运行 velero restore create 时:

1. Velero客户端会调用Kubernetes API服务器来创建一个 Restore 对象
2. RestoreController 注意到新的 Restore 对象并进行验证
3. RestoreController 从对象存储服务中获取备份信息。然后，它在备份的资源上运行一些预处理，以确保资源能在新的集群上工作。例如，使用 backed-up API versions 来验证还原资源将在目标集群上工作
4. RestoreController 启动还原过程，每次都会对每个符合条件的资源进行还原

默认情况下，Velero 执行的是非破坏性还原，意味着它不会删除目标集群上的任何数据。如果备份中的某个资源已经存在于目标集群中，Velero 将跳过该资源;

可以使用 --existing-resource-policy restore 标志来配置 Velero 使用更新策略, 当这个标志被设置为 update 时，Velero 将尝试更新目标集群中的现有资源，以匹配备份中的资源.

关于 Velero 还原过程的更多细节，请参见 还原参考页面

Backed-up API versions

Velero 使用 Kubernetes API 服务器对每个 group/resource 的首选版本备份资源。当恢复一个资源时，这个相同的 API group/version 必须存在于目标集群中，以便恢复成功。

例如，如果被备份的集群在 things API 组中有一个 gizmos 资源，group/versions 为 things/v1alpha1、things/v1beta1 和 things/v1，而服务器的首选 group/versions 为

things/v1，那么所有 gizmos 将从 things/v1 API 端点进行备份。当从该群集恢复备份时，目标群集必须有 things/v1 端点，以使 gizmos 被恢复。

请注意，things/v1不需要是目标集群中的首选版本；它只需要存在。

将备份设置为过期

当创建一个备份时，可以通过添加标志 --ttl <DURATION> 来指定一个TTL(生存时间), 如果 Velero 看到一个现有的备份资源过期了，它会删除:

. 备份资源

. 云对象存储中的备份文件

. 所有 PersistentVolume 快照

. 所有相关的恢复

TTL 标志允许用户指定备份保留期，其值以小时、分钟和秒为单位，格式为 --ttl 24h0m0s 如果不指定，将应用默认的 TTL 值 30 天.

如果备份删除失败，一个标签 velero.io/gc-failure=<Reason> 将被添加到备份自定义资源中.

可以使用这个标签来过滤和选择未能删除的备份.

已实现的原因有:

. BSLNotFound: 未找到备份存储位置

. BSLCannotGet: 由于未找到以外的原因，无法从 API 服务器检索到备份存储位置

. BSLReadOnly: 备份存储位置是只读的

对象存储同步

Velero 不断检查正确的备份资源是否始终存在, 如果在存储桶中有一个正确格式的备份文件，但在 Kubernetes API 中没有相应的备份资源，Velero 会将信息从对象存储同步到 Kubernetes.

这允许恢复功能在集群迁移的情况下工作，在新的集群中不存在原始备份对象.

同样的，如果一个 Completed 备份对象在 Kubernetes 中存在，但在对象存储中不存在，它将从 Kubernetes 中删除，因为备份的 tarball 不再存在, Failed 或 PartiallyFailed 的备份将不会被对象存储同步删除.