VeleroHeptio Ark架构指南理解备份、调度、恢复与对象存储同步的完整机制【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero导读本文以仓库文档 site/content/docs/v0.7.1/about.md 为骨架系统讲解 Velero前身 Heptio Ark作为 Kubernetes 备份与迁移方案的核心工作原理它如何通过 CRD 自定义控制器实现按需备份、定时备份与恢复备份数据如何上传到对象存储对象存储又如何作为真相源反向同步回集群。读完本文你将掌握 Velero 的三大操作模型、备份/恢复的底层调用链、TTL 过期清理机制以及 restore-only 模式的适用场景并能结合仓库源码定位到每个机制对应的控制器实现。一、Velero 是什么可定制的 Kubernetes 恢复方案Velero本文所依据的 v0.7.1 时代文档中名为Heptio Ark后随项目并入 VMware 更名为 Velero为所有 Kubernetes 对象——包括 Pod、Deployment、Job、Custom Resource DefinitionCRD等——以及持久卷PersistentVolume提供可定制的恢复能力[恢复范围控制]见下文精细过滤小节。这种恢复能力有两种典型的应用方式集群级恢复disaster recovery整个集群的对象与持久卷整体备份与还原细粒度恢复按对象类型resource、命名空间namespace或标签label精确指定备份与恢复的范围从而实现只恢复某几个业务命名空间这类场景。此外Velero 非常适合在对集群执行系统级操作如升级之前先对应用状态做快照为操作失败预留回退手段。当前仓库仍完整保留着这套以自定义资源Backup / Schedule / Restore为核心的架构只是将 Ark 时代的自定义资源名统一演进为velero.ioAPI 组下的对象下文将以当前仓库实现为准展开。二、核心架构CRD 驱动的三种操作Velero 提供三种核心操作全部以 Kubernetes自定义资源CRD的形式存在并持久化在 etcd 中On-demand backups按需备份Scheduled backups定时备份Restores恢复除了这三个操作对象还有一个名为Config的附加自定义资源在 v0.7.1 文档中的叫法当前仓库中对应职责由 BackupStorageLocation 与 VolumeSnapshotLocation 等资源承载用于指定必要信息与自定义选项例如云提供商设置。当这些请求被提交到 Kubernetes API server 后由对应的自定义控制器custom controllers负责处理。每个控制器都 watch 自己的自定义资源以感知 API 请求即 Velero 操作执行校验并处理与云提供商 API 交互的逻辑——典型如管理对象存储、管理持久卷快照。从当前仓库源码可以看到这组控制器都集中在 pkg/controller 目录下控制器源码文件职责BackupControllerpkg/controller/backup_controller.go校验并执行 Backup 资源对应的备份流程ScheduleControllerpkg/controller/schedule_controller.go按 Cron 表达式触发定时备份RestoreControllerpkg/controller/restore_controller.go根据 Backup 还原对象与卷BackupSyncControllerpkg/controller/backup_sync_controller.go将对象存储中的备份元数据同步回集群各操作对应的 API 类型定义集中在 pkg/apis/velero/v1 下例如 backup_types.go 定义了BackupSpec其中包含IncludedNamespaces、ExcludedNamespaces、IncludedResources、LabelSelector、SnapshotVolumes、TTL等字段见 backup_types.go——这正是前文按对象类型、命名空间或标签精确恢复的落地形式。2.1 按需备份On-demand backupsbackup操作的核心流程分两步将收集到的 Kubernetes 对象打包成 tarball上传到云对象存储如 AWS S3如果指定了卷快照则调用云提供商 API 为持久卷创建磁盘快照。在备份过程中你可以可选地指定hooks在备份期间执行。典型场景是在对数据库卷打快照之前先通过 hook 通知数据库将内存缓冲 flush 到磁盘以保证快照数据一致性。关于 hooks 的完整机制可参考仓库中 internal/hook 目录下的item_hook_handler.go、wait_exec_hook_handler.go及其测试文件。需要特别说明的局限集群备份并非严格原子strictly atomic的。如果在备份进行时 Kubernetes 对象正在被创建或编辑这些对象可能不会被包含进备份。捕获到不一致信息的概率很低但确实存在——这正是官方文档明确提示的使用边界。2.2 定时备份Scheduled backupsschedule操作允许你按固定周期重复备份数据第一次备份在Schedule 首次创建时立即执行之后的备份按照 Schedule 中指定的Cron 表达式所规定的时间间隔执行Schedule 本质上是 Backup 的包装器wrapper被触发时它在后台创建 Backup 对象。定时备份生成的备份对象命名为SCHEDULE NAME-TIMESTAMP其中TIMESTAMP的格式为YYYYMMDDhhmmss。从当前仓库源码 schedule_controller.go 可以印证这套实现细节parseCronSchedule使用cron.ParseStandard解析Spec.Schedule若 Cron 表达式非法或为空则将 Schedule 置为SchedulePhaseFailedValidation并记录校验错误见 schedule_controller.goifDue判断当前是否到达触发时刻checkIfBackupInNewOrProgress会检查该 Schedule 是否已有处于 New / InProgress 状态的备份以避免产生重叠的定时备份见 schedule_controller.go控制器周期scheduleSyncPeriod time.Minute见 schedule_controller.go并通过velero.io/schedule-name标签定义在 labels_annotations.go标识某次备份由哪个 Schedule 产生。2.3 恢复Restoresrestore操作允许你从之前创建的 Backup 中还原所有对象与持久卷。Velero 支持多命名空间重映射multiple namespace remapping——例如在单次恢复中将命名空间abc中的对象重建到命名空间def下同时把123中的对象重建到456下。被恢复的 Kubernetes 对象可以通过一个标签来识别标签形如ark-restoreBACKUP NAME-TIMESTAMP其中TIMESTAMP格式为YYYYMMDDhhmmss。当前仓库中该标签已演进为velero.io/restore-name见 labels_annotations.go并在恢复流程中由 pkg/restore/restore.go 的addRestoreLabels逻辑在还原对象时统一打上见 restore.go。此外恢复控制器内置了一个排除清单nonRestorableResources例如 nodes、events、backups.velero.io、restores.velero.io、csinodes.storage.k8s.io等集群级或 Velero 自身管理的资源不会被还原见 restore_controller.go——这保证了恢复过程不会污染目标集群的基础设施状态。restore-only 模式你还可以让 Velero 服务端以仅恢复模式运行。该模式在灾难恢复期间禁用 backup、schedule 与垃圾回收garbage collection功能只保留恢复能力避免灾备集群被误写备份数据。从当前仓库源码 pkg/cmd/server/server.go 可以看到该模式通过启动参数--restore-only开启一旦开启服务端会将 Backup、BackupDeletion、BackupFinalizer、BackupOperations、GarbageCollection、Schedule 等控制器全部加入DisabledControllers列表。同时该 flag 在 config.go 中被标注为DEPRECATED计划在 v2.0 移除官方建议改用只读的备份存储位置read-only backup storage locations来实现同等隔离效果——使用时请注意版本差异。三、备份工作流从 CLI 到对象存储的完整调用链官方文档以ark backup create test-backup为例当前仓库对应命令为velero backup create test-backup完整描述了一次按需备份的四个步骤客户端创建对象Ark/Velero 客户端调用 Kubernetes API server创建一个Backup对象控制器发现并校验BackupController注意到新的Backup对象执行校验收集数据BackupController开始备份流程通过查询 API server 收集需要备份的数据上传对象存储BackupController调用对象存储服务例如 AWS S3上传备份文件。在 backup_controller.go 中可以找到与这四个步骤对应的实现证据控制器只处理处于BackupPhaseReadyToStart状态的 Backup见 backup_controller.go校验失败则置为BackupPhaseFailedValidation否则置为BackupPhaseInProgress并记录StartTimestamp见 backup_controller.go通过b.backupTracker跟踪正在执行的备份避免并发冲突见 backup_controller.go执行与上传的核心逻辑封装在b.runBackup(request)中任何错误都会将 Backup 置为BackupPhaseFailed并写入FailureReason见 backup_controller.go备份完成后根据结果进入Completed、PartiallyFailed、Failed等终态并清理backupTracker。另外需要注意备份默认行为默认情况下ark backup create即velero backup create会对所有引用的持久卷创建磁盘快照可以通过附加 flags 调整快照行为其中--snapshot-volumesfalse用于显式禁用卷快照。对应的字段定义在 backup_types.go 的SnapshotVolumes *bool。关于各 CLI 参数的具体含义可进一步查看 pkg/cmd/cli 目录下的 backup/schedule/restore 子命令实现。四、设置备份过期TTL 机制与清理范围创建备份时可以通过 flag 指定 TTL生存时间--ttl DURATION一旦 Ark/Velero 发现某个 Backup 资源已过期它会清理以下全部内容Backup 资源本身集群中的自定义资源对象存储中的备份文件所有相关的 PersistentVolume 快照所有关联的 Restores。在 backup_types.go 中TTL metav1.Duration被描述为一个 time.Duration 可解析的字符串描述 Backup 应被保留多久其默认值由服务端配置defaultBackupTTL见 backup_controller.go 的 reconciler 构造参数提供。过期备份的物理清理由独立的控制器完成——仓库中对应实现为 pkg/controller/backup_deletion_controller.go 与 pkg/controller/gc_controller.go前者负责按删除请求拆除备份的各类关联产物后者负责周期性扫描过期备份。五、对象存储同步以对象存储为真相源Velero 将对象存储视为真相源source of truth并持续检查确保正确的 Backup 资源始终存在。其同步逻辑是如果存储桶中存在格式正确的备份文件但 Kubernetes API 中没有对应的 Backup 资源Velero 会将信息从对象存储同步回 Kubernetes创建对应的 Backup 自定义资源。这一机制让恢复功能能够在集群迁移cluster migration场景下正常工作——新集群中原本不存在原集群的 Backup 对象通过对象存储同步即可重建这些元数据从而执行恢复。当前仓库中对应的实现是 pkg/controller/backup_sync_controller.go同步周期为backupSyncReconcilePeriod time.Minute见 backup_sync_controller.go控制器先通过backupStore.ListBackups()列出对象存储中的全部备份再列出集群中的全部 Backup 资源然后用集合差运算backupStoreBackups.Difference(clusterBackupsSet)求出在对象存储中存在、但在集群中缺失的备份将其同步进集群见 backup_sync_controller.go若 BackupStorageLocation 处于不可用状态则跳过同步见 backup_sync_controller.go。这个对象存储 → 集群的单向同步方向保证了即使集群 etcd 中的 Backup 元数据丢失只要对象存储完好备份仍可通过同步被重新发现并用于恢复。六、设计延伸从 Ark 到 Velero 的演进要点最后补充几点从当前仓库中可以确认的演进事实帮助读者在阅读旧文档如 v0.7.1与使用新版本时对齐概念命名变化CLI 命令由ark变为velero资源标签由ark-restore演进为velero.io/restore-name等标准标签见 labels_annotations.goCRD 分组所有自定义资源归属于velero.ioAPI 组类型定义见 pkg/apis/velero/v1 下的各*_types.go文件恢复排除清单为保障跨集群恢复安全恢复控制器显式排除了 nodes、events、backups.velero.io等资源见 restore_controller.gorestore-only 模式过渡该模式仍然可用但已标记废弃官方方向是使用只读备份存储位置见 config.go。结语通过对 site/content/docs/v0.7.1/about.md 与当前仓库源码的对照阅读可以看到Velero 的备份体系始终围绕CRD 定义操作、控制器驱动执行、对象存储承载数据与元数据这一清晰架构展开Backup 负责收集对象并上传 tarball 与卷快照Schedule 用 Cron 表达式包装并触发 BackupRestore 负责还原并支持命名空间重映射BackupSync 则让对象存储成为可靠的元数据真相源。理解这条调用链是排查备份失败、设计灾备方案以及二次开发 Velero 插件的第一步。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考