Velero 工作原理全解自定义资源驱动 Kubernetes 备份、恢复与调度【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/veleroVelero本项目仓库名GitHub_Trending/ve/velero是一套以Kubernetes 自定义资源CRD 控制器Controller为核心架构的备份与迁移工具。本篇技术指南围绕 v0.11.0 版官方文档 展开完整讲解按需备份、定时备份、恢复、备份工作流、API 版本处理、TTL 过期清理与对象存储同步的底层机制。读完本文你将掌握 Velero 的端到端工作链路并能结合 Backup CRD 定义 与各控制器源码如 backup_controller.go理解其行为边界为实际灾备与集群迁移提供可验证的方案。一切皆自定义资源Velero 的设计基石Velero 的每类核心操作——按需备份on-demand backup、定时备份scheduled backup、恢复restore——都是一个自定义资源对象通过 Kubernetes 的 Custom Resource Definition (CRD) 声明并被持久化存储在集群的etcd中。同时 Velero 内置一组控制器controllers负责监听这些自定义资源的变化并执行备份、恢复及所有关联操作。这一设计带来的直接好处是备份、恢复等操作天然具备 Kubernetes 原生的声明式、可审计、可查询特性可用kubectl get backups.velero.io等方式直接查看控制平面组件BackupController、ScheduleController、RestoreController等彼此解耦通过 API 对象的状态机协作用户既可以执行 CLI 命令也可以直接以 YAML 形式创建自定义资源。从 apis/velero/v1 目录 可以看到Backup、Schedule、Restore等 API 类型的 Go 定义例如 backup_types.go 中的BackupSpec以includedNamespaces、excludedNamespaces、includedResources、excludedResources等字段描述“备份什么、不备份什么”。这意味着你可以备份集群中的全部对象也可以按资源类型type、命名空间namespace和/或标签label过滤后再备份。这种过滤能力与 CLI 参数一一对应。查看 backup create 命令实现可以看到示例命令# 备份全部资源 velero backup create backup1 # 仅备份 nginx 命名空间 velero backup create nginx-backup --include-namespaces nginx # 排除 velero 与 default 命名空间 velero backup create backup2 --exclude-namespaces velero,default # 基于某个定时备份计划创建一次备份 velero backup create --from-schedule daily-backup # 生成不创建卷快照的备份 YAML不发往服务端 velero backup create backup3 --snapshot-volumesfalse -o yaml # 等待备份完成后命令才返回 velero backup create backup4 --wait按需备份两步核心动作backup备份操作本质上是两步动作将复制出的 Kubernetes 对象打包成tarball上传到云对象存储如 AWS S3如果指定了快照则调用云厂商 API 为持久卷PersistentVolume创建磁盘快照。通过 Hooks 保证数据一致性备份过程中可以可选地指定hooks钩子在备份时执行。典型场景是在快照前让数据库把内存缓冲区 flush 到磁盘。关于 hooks 的完整配置可参阅 hooks.md其中 v0.7.0 之后同时支持 pre自定义 action 处理之前与 post所有自定义 action 及附加项备份完成之后两类钩子可通过 Pod 注解或 Backup spec 两种方式声明。例如用pre.hook.backup.velero.io/command[/sbin/fsfreeze, --freeze, /var/log/nginx]冻结文件系统后再快照。非严格原子性的说明需要特别强调的是集群备份并非严格原子。如果在备份进行的同时有 Kubernetes 对象正在被创建或编辑它们可能不会被包含进本次备份。文档原话是“捕获到不一致信息的概率很低但确实存在”——这是由“先查询 API Server 收集对象、再打包上传”的非事务性流程决定的规划备份窗口时应将其纳入考虑。定时备份Cron 表达式驱动的 Scheduleschedule定时备份操作允许你按固定时间间隔反复备份数据。行为要点如下首次备份在 schedule 首次创建时立即执行之后的备份按照指定的时间间隔触发间隔由Cron 表达式描述定时生成的备份以SCHEDULE NAME-TIMESTAMP命名其中TIMESTAMP格式为YYYYMMDDhhmmss。该命名规则在源码中有直接印证pkg/apis/velero/v1/schedule_types.go的TimestampedName方法实现为fmt.Sprintf(%s-%s, s.Name, timestamp.Format(20060102150405))见 schedule_types.go。从 schedule_controller.go 可以看到 Cron 表达式的解析与校验流程parseCronSchedule使用cron.ParseStandard解析spec.schedule对空字符串或非法表达式会记录SchedulePhaseFailedValidation与validationErrors此外控制器会通过checkIfBackupInNewOrProgressschedule_controller.go检查该 schedule 是否已有处于New/InProgress状态的备份以避免重叠执行。submitBackup中则用getBackup(schedule, now)按时间戳生成 Backup 对象并通过 controller-runtime 的 client 直接Createschedule_controller.go随后更新schedule.Status.LastBackup。恢复全量或过滤 多命名空间重映射restore恢复操作允许你从先前创建的备份中恢复全部或部分对象与持久卷。核心能力支持只恢复被过滤后的对象/持久卷子集支持多个命名空间重映射例如在单次恢复中命名空间abc中的对象可重建到def命名空间123中的对象重建到456。关于默认命名与标签恢复默认名为BACKUP NAME-TIMESTAMPTIMESTAMP格式同为YYYYMMDDhhmmss也可自定义名称每个被恢复的对象都会被打上键为velero.io/restore-name、值为RESTORE NAME的标签。标签常量定义见 labels_annotations.goRestoreNameLabel velero.io/restore-name并被 backup_pv_action.go 等备份 action 用于处理 PV 相关资源。restore-only仅恢复模式Velero 服务器还可以运行在restore-only仅恢复模式下该模式会禁用备份、调度和垃圾回收功能专用于灾备恢复场景。在 server 配置 中对应--restore-only标志velero server --restore-only该标志在 server.go 中被消费用于跳过备份/调度/GC 相关控制器的启动。文档同时指出该标志已标记为弃用计划在 v2.0 移除建议改用只读read-onlyBackupStorageLocation达到同样的效果——即把存储位置设置为AccessMode: ReadOnlyVelero 在创建备份时会对处于只读模式的存储位置报校验错误见 backup_controller.go。备份工作流velero backup create的完整链路文档以velero backup create test-backup为例给出了四步工作流Velero 客户端调用 Kubernetes API Server创建一个Backup对象BackupController发现新的Backup对象并执行校验BackupController启动备份过程通过查询 API Server 收集需要备份的数据BackupController调用对象存储服务如 AWS S3上传备份文件。这张示意图完整呈现了上述链路左侧用户经velero client提交velero backup create test-backup --snapshot-volumes中间 Kubernetes API 将BackupCR 持久化到 etcd 并通知BackupController随后控制器查询 API/etcd 收集资源、向 cloud provider 上传 tarball并通过云 API 对磁盘做快照。从源码看当前仓库中该流程的落地与文档描述完全吻合BackupController即 backup_controller.go 中的Reconcile方法。它只处理ReadyToStart阶段的 Backup第 298-307 行随后调用prepareBackupRequest做校验并置为InProgress校验覆盖存储位置是否存在/可用、卷快照位置VolumeSnapshotLocation是否合法、include/exclude 过滤参数是否冲突等prepareBackupRequest实际执行在runBackupbackup_controller.go创建双模式日志、启动插件管理器、检查对象存储中是否已存在同名备份然后调用backupper.BackupWithResolvers(...)完成资源收集与 tarball 生成最后由persistBackup将备份 JSON、日志、快照列表、结果等一并上传到对象存储。默认情况下velero backup create会对任何持久卷创建磁盘快照可通过附加标志调整velero backup create --help可查看全部标志用--snapshot-volumesfalse可关闭快照。该标志在 create.go 中以OptionalBool形式定义未显式设置时按true处理。其他常用标志还包括--ttl、--include-namespaces、--exclude-namespaces、--include-resources、--labels、--selector、--storage-location等完整列表见 CreateOptions。备份使用的 API 版本以首选版本为准Velero 使用 Kubernetes API Server 返回的首选版本preferred version备份每个 group/resource。恢复时目标集群中必须存在相同的 API group/version 才能成功恢复。文档给出的示例非常清晰假设被备份集群的thingsAPI 组下有gizmos资源其 group/version 为things/v1alpha1、things/v1beta1、things/v1且服务端首选版本是things/v1那么所有gizmos都会从things/v1端点备份。恢复该备份时目标集群必须提供things/v1端点但things/v1不要求是目标集群的首选版本只需存在即可。在实现层面pkg/discovery/helper.go默认调用discoveryClient.ServerPreferredResources()填充资源列表helper.go仅当启用了EnableAPIGroupVersions特性开关时才会改用ServerGroupsAndResources()获取全量版本。备份目录中也存在PreferredVersionDir这样的目录结构约定见 item_backupper.go印证了“按首选版本组织备份内容”的实现方式。设置备份过期TTL 与清理范围创建备份时可通过--ttl DURATION标志指定备份的存活时间TTL。一旦 Velero 发现某个备份资源已过期会清理以下内容Backup 资源本身自定义资源对象对象存储中的备份文件tarball全部 PersistentVolume 快照所有关联的 RestoresTTL 的计算在源码中体现为BackupController的prepareBackupRequest中若用户未指定 TTL 则使用服务端默认值随后计算request.Status.Expiration now spec.ttlbackup_controller.go。过期清理由backup_deletion_controller.go执行其中还包含deleteBackupRequestMaxAge 24 * time.Hour这样的保护性常量backup_deletion_controller.go确保过期请求最终可被回收。对象存储同步以对象存储为唯一事实来源Velero 将对象存储视为事实来源source of truth并持续检查正确的备份资源是否始终存在。同步规则如下如果存储桶中存在格式正确的备份文件但 Kubernetes API 中没有对应的 Backup 资源Velero 会将信息从对象存储同步到 Kubernetes创建对应的 Backup 资源反过来如果 Kubernetes 中存在 Backup 对象但对象存储中没有对应的备份 tarball则该 Backup 对象会被从 Kubernetes 中删除。这一机制使得集群迁移场景下的恢复成为可能当原集群中的 Backup 对象在新集群中不存在时只要对象存储里的备份文件还在新集群的 Velero 就能通过同步重新发现备份并执行恢复。实现该行为的是 backup_sync_controller.gobackupSyncReconciler.Reconcile会先确认 BackupStorageLocation 处于可用状态然后通过backupStore.ListBackups()列出对象存储中所有备份与集群内的BackupList做比对据此创建缺失的 Backup 资源或删除“孤儿”备份对象。它按backupSyncReconcilePeriod time.Minute周期性地对每个存储位置执行同步backup_sync_controller.go。典型应用场景小结结合 v0.11.0 about.md 与仓库源码可以归纳出 Velero 的典型使用方式场景推荐方式关键点灾难恢复定期velero schedule create 恢复时用velero restore create --from-backup对象存储同步机制保证新集群可直接发现备份必要时以--restore-only或只读 BSL 加固集群升级前的状态快照按需velero backup create配合 pre/post hooks 保证一致用--ttl控制快照保留时长非原子性要求升级窗口尽量避开发布活动集群迁移/命名空间重映射单次 restore 中通过参数将源命名空间映射到目标命名空间目标集群需具备备份时使用的 API group/version 端点细粒度备份--include-namespaces/--exclude-resources/--selector组合对应BackupSpec的过滤字段语义可在 backup_types.go 中核对Velero 的架构核心在于“自定义资源定义意图、控制器执行意图、对象存储沉淀事实”理解这三层关系就能准确预判备份/恢复在各种边界条件下的行为并基于源码定位问题——这正是把本文各节串联起来的主线。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Velero 工作原理全解：自定义资源驱动 Kubernetes 备份、恢复与调度
Velero 工作原理全解自定义资源驱动 Kubernetes 备份、恢复与调度【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/veleroVelero本项目仓库名GitHub_Trending/ve/velero是一套以Kubernetes 自定义资源CRD 控制器Controller为核心架构的备份与迁移工具。本篇技术指南围绕 v0.11.0 版官方文档 展开完整讲解按需备份、定时备份、恢复、备份工作流、API 版本处理、TTL 过期清理与对象存储同步的底层机制。读完本文你将掌握 Velero 的端到端工作链路并能结合 Backup CRD 定义 与各控制器源码如 backup_controller.go理解其行为边界为实际灾备与集群迁移提供可验证的方案。一切皆自定义资源Velero 的设计基石Velero 的每类核心操作——按需备份on-demand backup、定时备份scheduled backup、恢复restore——都是一个自定义资源对象通过 Kubernetes 的 Custom Resource Definition (CRD) 声明并被持久化存储在集群的etcd中。同时 Velero 内置一组控制器controllers负责监听这些自定义资源的变化并执行备份、恢复及所有关联操作。这一设计带来的直接好处是备份、恢复等操作天然具备 Kubernetes 原生的声明式、可审计、可查询特性可用kubectl get backups.velero.io等方式直接查看控制平面组件BackupController、ScheduleController、RestoreController等彼此解耦通过 API 对象的状态机协作用户既可以执行 CLI 命令也可以直接以 YAML 形式创建自定义资源。从 apis/velero/v1 目录 可以看到Backup、Schedule、Restore等 API 类型的 Go 定义例如 backup_types.go 中的BackupSpec以includedNamespaces、excludedNamespaces、includedResources、excludedResources等字段描述“备份什么、不备份什么”。这意味着你可以备份集群中的全部对象也可以按资源类型type、命名空间namespace和/或标签label过滤后再备份。这种过滤能力与 CLI 参数一一对应。查看 backup create 命令实现可以看到示例命令# 备份全部资源 velero backup create backup1 # 仅备份 nginx 命名空间 velero backup create nginx-backup --include-namespaces nginx # 排除 velero 与 default 命名空间 velero backup create backup2 --exclude-namespaces velero,default # 基于某个定时备份计划创建一次备份 velero backup create --from-schedule daily-backup # 生成不创建卷快照的备份 YAML不发往服务端 velero backup create backup3 --snapshot-volumesfalse -o yaml # 等待备份完成后命令才返回 velero backup create backup4 --wait按需备份两步核心动作backup备份操作本质上是两步动作将复制出的 Kubernetes 对象打包成tarball上传到云对象存储如 AWS S3如果指定了快照则调用云厂商 API 为持久卷PersistentVolume创建磁盘快照。通过 Hooks 保证数据一致性备份过程中可以可选地指定hooks钩子在备份时执行。典型场景是在快照前让数据库把内存缓冲区 flush 到磁盘。关于 hooks 的完整配置可参阅 hooks.md其中 v0.7.0 之后同时支持 pre自定义 action 处理之前与 post所有自定义 action 及附加项备份完成之后两类钩子可通过 Pod 注解或 Backup spec 两种方式声明。例如用pre.hook.backup.velero.io/command[/sbin/fsfreeze, --freeze, /var/log/nginx]冻结文件系统后再快照。非严格原子性的说明需要特别强调的是集群备份并非严格原子。如果在备份进行的同时有 Kubernetes 对象正在被创建或编辑它们可能不会被包含进本次备份。文档原话是“捕获到不一致信息的概率很低但确实存在”——这是由“先查询 API Server 收集对象、再打包上传”的非事务性流程决定的规划备份窗口时应将其纳入考虑。定时备份Cron 表达式驱动的 Scheduleschedule定时备份操作允许你按固定时间间隔反复备份数据。行为要点如下首次备份在 schedule 首次创建时立即执行之后的备份按照指定的时间间隔触发间隔由Cron 表达式描述定时生成的备份以SCHEDULE NAME-TIMESTAMP命名其中TIMESTAMP格式为YYYYMMDDhhmmss。该命名规则在源码中有直接印证pkg/apis/velero/v1/schedule_types.go的TimestampedName方法实现为fmt.Sprintf(%s-%s, s.Name, timestamp.Format(20060102150405))见 schedule_types.go。从 schedule_controller.go 可以看到 Cron 表达式的解析与校验流程parseCronSchedule使用cron.ParseStandard解析spec.schedule对空字符串或非法表达式会记录SchedulePhaseFailedValidation与validationErrors此外控制器会通过checkIfBackupInNewOrProgressschedule_controller.go检查该 schedule 是否已有处于New/InProgress状态的备份以避免重叠执行。submitBackup中则用getBackup(schedule, now)按时间戳生成 Backup 对象并通过 controller-runtime 的 client 直接Createschedule_controller.go随后更新schedule.Status.LastBackup。恢复全量或过滤 多命名空间重映射restore恢复操作允许你从先前创建的备份中恢复全部或部分对象与持久卷。核心能力支持只恢复被过滤后的对象/持久卷子集支持多个命名空间重映射例如在单次恢复中命名空间abc中的对象可重建到def命名空间123中的对象重建到456。关于默认命名与标签恢复默认名为BACKUP NAME-TIMESTAMPTIMESTAMP格式同为YYYYMMDDhhmmss也可自定义名称每个被恢复的对象都会被打上键为velero.io/restore-name、值为RESTORE NAME的标签。标签常量定义见 labels_annotations.goRestoreNameLabel velero.io/restore-name并被 backup_pv_action.go 等备份 action 用于处理 PV 相关资源。restore-only仅恢复模式Velero 服务器还可以运行在restore-only仅恢复模式下该模式会禁用备份、调度和垃圾回收功能专用于灾备恢复场景。在 server 配置 中对应--restore-only标志velero server --restore-only该标志在 server.go 中被消费用于跳过备份/调度/GC 相关控制器的启动。文档同时指出该标志已标记为弃用计划在 v2.0 移除建议改用只读read-onlyBackupStorageLocation达到同样的效果——即把存储位置设置为AccessMode: ReadOnlyVelero 在创建备份时会对处于只读模式的存储位置报校验错误见 backup_controller.go。备份工作流velero backup create的完整链路文档以velero backup create test-backup为例给出了四步工作流Velero 客户端调用 Kubernetes API Server创建一个Backup对象BackupController发现新的Backup对象并执行校验BackupController启动备份过程通过查询 API Server 收集需要备份的数据BackupController调用对象存储服务如 AWS S3上传备份文件。这张示意图完整呈现了上述链路左侧用户经velero client提交velero backup create test-backup --snapshot-volumes中间 Kubernetes API 将BackupCR 持久化到 etcd 并通知BackupController随后控制器查询 API/etcd 收集资源、向 cloud provider 上传 tarball并通过云 API 对磁盘做快照。从源码看当前仓库中该流程的落地与文档描述完全吻合BackupController即 backup_controller.go 中的Reconcile方法。它只处理ReadyToStart阶段的 Backup第 298-307 行随后调用prepareBackupRequest做校验并置为InProgress校验覆盖存储位置是否存在/可用、卷快照位置VolumeSnapshotLocation是否合法、include/exclude 过滤参数是否冲突等prepareBackupRequest实际执行在runBackupbackup_controller.go创建双模式日志、启动插件管理器、检查对象存储中是否已存在同名备份然后调用backupper.BackupWithResolvers(...)完成资源收集与 tarball 生成最后由persistBackup将备份 JSON、日志、快照列表、结果等一并上传到对象存储。默认情况下velero backup create会对任何持久卷创建磁盘快照可通过附加标志调整velero backup create --help可查看全部标志用--snapshot-volumesfalse可关闭快照。该标志在 create.go 中以OptionalBool形式定义未显式设置时按true处理。其他常用标志还包括--ttl、--include-namespaces、--exclude-namespaces、--include-resources、--labels、--selector、--storage-location等完整列表见 CreateOptions。备份使用的 API 版本以首选版本为准Velero 使用 Kubernetes API Server 返回的首选版本preferred version备份每个 group/resource。恢复时目标集群中必须存在相同的 API group/version 才能成功恢复。文档给出的示例非常清晰假设被备份集群的thingsAPI 组下有gizmos资源其 group/version 为things/v1alpha1、things/v1beta1、things/v1且服务端首选版本是things/v1那么所有gizmos都会从things/v1端点备份。恢复该备份时目标集群必须提供things/v1端点但things/v1不要求是目标集群的首选版本只需存在即可。在实现层面pkg/discovery/helper.go默认调用discoveryClient.ServerPreferredResources()填充资源列表helper.go仅当启用了EnableAPIGroupVersions特性开关时才会改用ServerGroupsAndResources()获取全量版本。备份目录中也存在PreferredVersionDir这样的目录结构约定见 item_backupper.go印证了“按首选版本组织备份内容”的实现方式。设置备份过期TTL 与清理范围创建备份时可通过--ttl DURATION标志指定备份的存活时间TTL。一旦 Velero 发现某个备份资源已过期会清理以下内容Backup 资源本身自定义资源对象对象存储中的备份文件tarball全部 PersistentVolume 快照所有关联的 RestoresTTL 的计算在源码中体现为BackupController的prepareBackupRequest中若用户未指定 TTL 则使用服务端默认值随后计算request.Status.Expiration now spec.ttlbackup_controller.go。过期清理由backup_deletion_controller.go执行其中还包含deleteBackupRequestMaxAge 24 * time.Hour这样的保护性常量backup_deletion_controller.go确保过期请求最终可被回收。对象存储同步以对象存储为唯一事实来源Velero 将对象存储视为事实来源source of truth并持续检查正确的备份资源是否始终存在。同步规则如下如果存储桶中存在格式正确的备份文件但 Kubernetes API 中没有对应的 Backup 资源Velero 会将信息从对象存储同步到 Kubernetes创建对应的 Backup 资源反过来如果 Kubernetes 中存在 Backup 对象但对象存储中没有对应的备份 tarball则该 Backup 对象会被从 Kubernetes 中删除。这一机制使得集群迁移场景下的恢复成为可能当原集群中的 Backup 对象在新集群中不存在时只要对象存储里的备份文件还在新集群的 Velero 就能通过同步重新发现备份并执行恢复。实现该行为的是 backup_sync_controller.gobackupSyncReconciler.Reconcile会先确认 BackupStorageLocation 处于可用状态然后通过backupStore.ListBackups()列出对象存储中所有备份与集群内的BackupList做比对据此创建缺失的 Backup 资源或删除“孤儿”备份对象。它按backupSyncReconcilePeriod time.Minute周期性地对每个存储位置执行同步backup_sync_controller.go。典型应用场景小结结合 v0.11.0 about.md 与仓库源码可以归纳出 Velero 的典型使用方式场景推荐方式关键点灾难恢复定期velero schedule create 恢复时用velero restore create --from-backup对象存储同步机制保证新集群可直接发现备份必要时以--restore-only或只读 BSL 加固集群升级前的状态快照按需velero backup create配合 pre/post hooks 保证一致用--ttl控制快照保留时长非原子性要求升级窗口尽量避开发布活动集群迁移/命名空间重映射单次 restore 中通过参数将源命名空间映射到目标命名空间目标集群需具备备份时使用的 API group/version 端点细粒度备份--include-namespaces/--exclude-resources/--selector组合对应BackupSpec的过滤字段语义可在 backup_types.go 中核对Velero 的架构核心在于“自定义资源定义意图、控制器执行意图、对象存储沉淀事实”理解这三层关系就能准确预判备份/恢复在各种边界条件下的行为并基于源码定位问题——这正是把本文各节串联起来的主线。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考