Velero 工作原理深度解析CRD 驱动的 Kubernetes 备份、恢复与灾难恢复架构【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero导读Velero当前仓库项目名为 GitHub_Trending/ve/velero是面向 Kubernetes 集群的备份与迁移工具。本文基于官方文档 site/content/docs/v1.1.0/about.md 的核心内容系统讲解 Velero 的三大核心操作——按需备份、定时备份与恢复——如何以 Kubernetes 自定义资源CRD 控制器Controller的机制运转并结合当前仓库的源码实现pkg/apis/velero/v1/下的类型定义与pkg/controller/下的控制器进行纵深佐证。读完本文你将掌握 Velero 的完整工作流、备份/恢复的筛选机制、TTL 过期策略、对象存储同步原理以及如何在灾备与集群升级等真实场景中正确使用 Velero。Velero 的核心模型一切操作都是 Kubernetes 自定义资源Velero 最关键的设计思想是每一次操作——无论是按需备份、定时备份还是恢复——都被建模为一个 Kubernetes 自定义资源Custom Resource Definition, CRD并持久化存储在 etcd 中。与此同时Velero 内置了一组控制器controller负责持续监听并处理这些自定义资源从而驱动备份、恢复以及所有相关操作的实际执行。这一模型在当前仓库的 API 定义中有非常清晰的体现。pkg/apis/velero/v1/目录下定义了全部 Velero 核心资源类型backup_types.goBackup资源其BackupSpec是备份请求的完整规范schedule_types.goSchedule资源通过 Cron 表达式周期性触发备份restore_types.goRestore资源描述从哪个备份恢复、恢复哪些对象backupstoragelocation_types.goBackupStorageLocationBSL定义备份数据的存储位置。由于操作对象是标准 Kubernetes 资源用户既可以通过 Velero CLIvelero backup create ...提交请求也可以直接使用kubectl操作对应的 CRD 对象——两条路径最终都会在 API Server 上创建自定义资源再由控制器消费。基于资源模型的另一个重要能力是筛选你可以备份或恢复集群中的全部对象也可以按资源类型type、命名空间namespace和标签label精确筛选。对应地BackupSpec与RestoreSpec中都定义了IncludedNamespaces、ExcludedNamespaces、IncludedResources、ExcludedResources、LabelSelector等字段见 backup_types.go这些字段也正是velero backup create/velero restore create命令行中--include-namespaces、--exclude-resources、--selector等参数的直接落点。从使用场景上看Velero 主要面向两大类需求灾难恢复Disaster Recovery在集群故障后将整个集群状态恢复到可用的新集群系统变更前的状态快照例如在集群升级等系统级操作之前先对应用状态做一次快照以便变更失败时快速回退。按需备份On-demand Backups按需备份是 Velero 最基础的操作其执行过程包含两步将复制到的 Kubernetes 对象打包成 tarball 文件上传到云对象存储cloud object storage如果指定了卷快照则调用云服务商 API为持久卷PersistentVolume制作磁盘快照。你还可以在备份期间指定hooks钩子在特定时机执行自定义命令。典型场景是在给数据库所在卷拍摄快照之前先通知数据库把内存中的缓冲区 flush 到磁盘确保快照数据的一致性。关于 hooks 的完整说明见 site/content/docs/v1.1.0/hooks.md。需要特别提醒的一点是集群备份并不是严格原子atomic的。如果备份进行期间有 Kubernetes 对象正在被创建或修改它们可能不会被纳入本次备份。虽然捕获到不一致信息的概率很低但这种可能性是客观存在的在要求强一致性的生产场景中需要有所预期。定时备份Scheduled Backups定时备份由Schedule资源驱动允许你按固定时间间隔循环备份数据。其行为有两个要点首次备份在Schedule创建后立即执行后续备份按 Cron 表达式指定的时间间隔周期性执行。Cron 表达式定义在ScheduleSpec.Schedule字段中见 schedule_types.go。此外ScheduleSpec还支持Paused暂停调度、UseOwnerReferencesInBackup让 Schedule 成为其产生的 Backup 的属主引用等扩展字段。由定时备份产生的备份对象遵循统一的命名格式SCHEDULE NAME-TIMESTAMP其中TIMESTAMP的格式为YYYYMMDDhhmmss年 4 位 月 2 位 日 2 位 时 2 位 分 2 位 秒 2 位。这一格式直接对应源码中Schedule的TimestampedName方法——它使用20060102150405这个 Go 时间格式模板拼接名称见 schedule_types.go。例如名称为daily的 Schedule在 2026 年 9 月 16 日 07:42:06 触发的备份会命名为daily-20260916074206。恢复RestoresRestore资源支持从先前创建的备份中恢复全部对象和持久卷也支持只恢复筛选后的对象子集。其核心筛选与映射能力包括按命名空间、资源类型、标签筛选与备份一致RestoreSpec提供IncludedNamespaces、IncludedResources、LabelSelector等字段见 restore_types.go多命名空间重映射Namespace RemappingNamespaceMapping字段是一个源命名空间到目标命名空间的映射表。例如在单次恢复中可以把命名空间abc中的对象重建到命名空间def同时把123中的对象重建到456见 restore_types.go。这一能力对跨集群迁移和同名冲突规避非常实用从 Schedule 恢复当BackupName为空而指定了ScheduleName时Velero 会从该 Schedule 最近一次成功的备份进行恢复。恢复对象的默认命名格式为BACKUP NAME-TIMESTAMP其中TIMESTAMP同样为YYYYMMDDhhmmss格式你也可以指定自定义名称。此外被恢复的对象会自动带上一个标签其键为velero.io/restore-name、值为RESTORE NAME。这一标签常量定义于 labels_annotations.go可用于后续检索、审计或区分本次恢复创建的对象。关于存储位置还有一个重要的运维细节默认情况下备份存储位置BackupStorageLocation以读写模式read-write创建。但在恢复场景中你可以将存储位置配置为只读模式read-only——该模式下会禁用此存储位置的备份创建与删除操作从而确保在恢复期间不会因为误操作而意外创建或删除备份。这一模式由BackupStorageLocationSpec.AccessMode字段控制见 backupstoragelocation_types.go。备份工作流从 CLI 到对象存储的完整链路当你在命令行执行velero backup create test-backup时背后发生了以下四个关键步骤提交 Backup 对象Velero 客户端调用 Kubernetes API Server创建一个Backup自定义资源控制器校验BackupController监听watch到新的Backup对象后对其进行校验收集数据BackupController开始备份流程通过查询 API Server 收集需要备份的资源数据上传存储BackupController调用对象存储服务例如 AWS S3上传备份文件。整个流程对应下图图片左侧展示了用户通过 Velero CLI 提交velero backup create test-backup --snapshot-volumes请求中间部分是BackupController通过 Kubernetes API 监听/查询资源右侧则是与云服务商cloud provider交互完成备份文件上传与磁盘快照创建。在控制器实现层面pkg/controller/backup_controller.go中定义的backupReconciler承担了监听、校验和执行备份的核心职责其resyncBackupMetrics等辅助逻辑见 backup_controller.go还负责在控制器重同步时校正备份指标。关于卷快照默认情况下velero backup create会为备份中包含的持久卷制作磁盘快照你可以通过附加标志调整行为。运行velero backup create --help可查看全部可用标志。其中最常用的一个参数是velero backup create test-backup --snapshot-volumesfalse即显式关闭卷快照——适合只想备份 Kubernetes 对象元数据、不需要复制卷数据的场景。该开关在BackupSpec.SnapshotVolumes字段中有直接对应见 backup_types.go。备份使用的 API 版本Backed-up API VersionsVelero 在备份资源时使用 Kubernetes API Server 对每个 group/resource 的**首选版本preferred version**进行采集。相应地在目标集群恢复该资源时相同的 API group/version 必须存在恢复才能成功。官方文档给出了一个非常直观的例子假设被备份的集群中存在thingsAPI group 下的gizmos资源其 group/version 依次为things/v1alpha1、things/v1beta1和things/v1而服务端首选版本是things/v1那么所有gizmos对象都会从things/v1端点被备份。当从这个集群的备份进行恢复时目标集群必须具备things/v1端点才能成功恢复gizmos。注意things/v1不需要是目标集群的首选版本它只需存在即可。这一按首选版本备份、按存在版本恢复的语义决定了跨集群迁移尤其是源集群与目标集群 Kubernetes 版本或 API 演进进度不一致时必须提前核对目标集群的 API 支持情况。设置备份过期时间TTL创建备份时可以通过--ttl DURATION标志指定备份的保留时长。一旦 Velero 发现某个已存在的备份资源过期它会自动清理与该备份关联的以下全部内容Backup资源本身云对象存储中的备份文件所有 PersistentVolume 快照所有关联的Restore资源。TTL字段类型为metav1.Duration即一个可被time.Duration解析的字符串见 backup_types.go例如720h30 天。TTL 机制的工程意义在于它让备份生命周期管理完全自动化——无需人工定时清理过期备份存储成本也会被控制在合理范围内。对象存储同步Object Storage Sync以对象存储为唯一事实来源Velero 的一个核心理念是对象存储object storage是唯一事实来源source of truth。Velero 会持续检查存储桶确保正确的备份资源始终存在于 Kubernetes 集群中如果存储桶中存在格式正确的备份文件但 Kubernetes API 中没有对应的Backup资源Velero 会将信息从对象存储同步到 Kubernetes反之如果Backup对象存在于 Kubernetes 但对应的备份 tarball 已不在对象存储中则该Backup对象会从 Kubernetes 中被删除。这一机制的实现主体是pkg/controller/backup_sync_controller.go中的backupSyncReconciler见 backup_sync_controller.go它会周期性扫描对象存储并反哺集群内的备份资源视图。对象存储同步带来的直接价值是在集群迁移场景下恢复功能依然可用——即便新集群中不存在原始的备份对象只要对象存储中仍有备份文件Velero 就能自动重建对应的Backup资源随后执行恢复。这构成了跨集群迁移与灾难恢复的数据基础。补充一点对象存储同步的频率等行为由BackupStorageLocationSpec中的BackupSyncPeriod定义对象存储到 API 的同步周期设为 0 可禁用同步与ValidationFrequency定义存储位置校验周期控制见 backupstoragelocation_types.go这两个字段支持细粒度运维调优。实践要点小结操作即资源备份、定时备份、恢复都是 CRD 控制器模式既可用veleroCLI 操作也可直接使用kubectl管理对应自定义资源筛选三要素类型resource、命名空间namespace、标签label组合出灵活的备份/恢复边界恢复阶段还支持多命名空间重映射备份非原子对一致性有强要求的应用建议结合 hooks 在快照前完成数据 flush快照默认开启不需要卷数据时记得用--snapshot-volumesfalse关闭节省成本TTL 自动化清理为每个备份设置合理 TTL避免过期数据长期占用存储对象存储即真相备份文件在对象存储中的存在与否直接决定Backup资源能否在集群中存活理解这一点对设计灾备与迁移方案至关重要。若需要进一步了解实际部署步骤安装、存储位置配置、首次备份演练可继续阅读同目录下的 install-overview.md、locations.md 与 get-started.md。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Velero 工作原理深度解析：CRD 驱动的 Kubernetes 备份、恢复与灾难恢复架构
Velero 工作原理深度解析CRD 驱动的 Kubernetes 备份、恢复与灾难恢复架构【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero导读Velero当前仓库项目名为 GitHub_Trending/ve/velero是面向 Kubernetes 集群的备份与迁移工具。本文基于官方文档 site/content/docs/v1.1.0/about.md 的核心内容系统讲解 Velero 的三大核心操作——按需备份、定时备份与恢复——如何以 Kubernetes 自定义资源CRD 控制器Controller的机制运转并结合当前仓库的源码实现pkg/apis/velero/v1/下的类型定义与pkg/controller/下的控制器进行纵深佐证。读完本文你将掌握 Velero 的完整工作流、备份/恢复的筛选机制、TTL 过期策略、对象存储同步原理以及如何在灾备与集群升级等真实场景中正确使用 Velero。Velero 的核心模型一切操作都是 Kubernetes 自定义资源Velero 最关键的设计思想是每一次操作——无论是按需备份、定时备份还是恢复——都被建模为一个 Kubernetes 自定义资源Custom Resource Definition, CRD并持久化存储在 etcd 中。与此同时Velero 内置了一组控制器controller负责持续监听并处理这些自定义资源从而驱动备份、恢复以及所有相关操作的实际执行。这一模型在当前仓库的 API 定义中有非常清晰的体现。pkg/apis/velero/v1/目录下定义了全部 Velero 核心资源类型backup_types.goBackup资源其BackupSpec是备份请求的完整规范schedule_types.goSchedule资源通过 Cron 表达式周期性触发备份restore_types.goRestore资源描述从哪个备份恢复、恢复哪些对象backupstoragelocation_types.goBackupStorageLocationBSL定义备份数据的存储位置。由于操作对象是标准 Kubernetes 资源用户既可以通过 Velero CLIvelero backup create ...提交请求也可以直接使用kubectl操作对应的 CRD 对象——两条路径最终都会在 API Server 上创建自定义资源再由控制器消费。基于资源模型的另一个重要能力是筛选你可以备份或恢复集群中的全部对象也可以按资源类型type、命名空间namespace和标签label精确筛选。对应地BackupSpec与RestoreSpec中都定义了IncludedNamespaces、ExcludedNamespaces、IncludedResources、ExcludedResources、LabelSelector等字段见 backup_types.go这些字段也正是velero backup create/velero restore create命令行中--include-namespaces、--exclude-resources、--selector等参数的直接落点。从使用场景上看Velero 主要面向两大类需求灾难恢复Disaster Recovery在集群故障后将整个集群状态恢复到可用的新集群系统变更前的状态快照例如在集群升级等系统级操作之前先对应用状态做一次快照以便变更失败时快速回退。按需备份On-demand Backups按需备份是 Velero 最基础的操作其执行过程包含两步将复制到的 Kubernetes 对象打包成 tarball 文件上传到云对象存储cloud object storage如果指定了卷快照则调用云服务商 API为持久卷PersistentVolume制作磁盘快照。你还可以在备份期间指定hooks钩子在特定时机执行自定义命令。典型场景是在给数据库所在卷拍摄快照之前先通知数据库把内存中的缓冲区 flush 到磁盘确保快照数据的一致性。关于 hooks 的完整说明见 site/content/docs/v1.1.0/hooks.md。需要特别提醒的一点是集群备份并不是严格原子atomic的。如果备份进行期间有 Kubernetes 对象正在被创建或修改它们可能不会被纳入本次备份。虽然捕获到不一致信息的概率很低但这种可能性是客观存在的在要求强一致性的生产场景中需要有所预期。定时备份Scheduled Backups定时备份由Schedule资源驱动允许你按固定时间间隔循环备份数据。其行为有两个要点首次备份在Schedule创建后立即执行后续备份按 Cron 表达式指定的时间间隔周期性执行。Cron 表达式定义在ScheduleSpec.Schedule字段中见 schedule_types.go。此外ScheduleSpec还支持Paused暂停调度、UseOwnerReferencesInBackup让 Schedule 成为其产生的 Backup 的属主引用等扩展字段。由定时备份产生的备份对象遵循统一的命名格式SCHEDULE NAME-TIMESTAMP其中TIMESTAMP的格式为YYYYMMDDhhmmss年 4 位 月 2 位 日 2 位 时 2 位 分 2 位 秒 2 位。这一格式直接对应源码中Schedule的TimestampedName方法——它使用20060102150405这个 Go 时间格式模板拼接名称见 schedule_types.go。例如名称为daily的 Schedule在 2026 年 9 月 16 日 07:42:06 触发的备份会命名为daily-20260916074206。恢复RestoresRestore资源支持从先前创建的备份中恢复全部对象和持久卷也支持只恢复筛选后的对象子集。其核心筛选与映射能力包括按命名空间、资源类型、标签筛选与备份一致RestoreSpec提供IncludedNamespaces、IncludedResources、LabelSelector等字段见 restore_types.go多命名空间重映射Namespace RemappingNamespaceMapping字段是一个源命名空间到目标命名空间的映射表。例如在单次恢复中可以把命名空间abc中的对象重建到命名空间def同时把123中的对象重建到456见 restore_types.go。这一能力对跨集群迁移和同名冲突规避非常实用从 Schedule 恢复当BackupName为空而指定了ScheduleName时Velero 会从该 Schedule 最近一次成功的备份进行恢复。恢复对象的默认命名格式为BACKUP NAME-TIMESTAMP其中TIMESTAMP同样为YYYYMMDDhhmmss格式你也可以指定自定义名称。此外被恢复的对象会自动带上一个标签其键为velero.io/restore-name、值为RESTORE NAME。这一标签常量定义于 labels_annotations.go可用于后续检索、审计或区分本次恢复创建的对象。关于存储位置还有一个重要的运维细节默认情况下备份存储位置BackupStorageLocation以读写模式read-write创建。但在恢复场景中你可以将存储位置配置为只读模式read-only——该模式下会禁用此存储位置的备份创建与删除操作从而确保在恢复期间不会因为误操作而意外创建或删除备份。这一模式由BackupStorageLocationSpec.AccessMode字段控制见 backupstoragelocation_types.go。备份工作流从 CLI 到对象存储的完整链路当你在命令行执行velero backup create test-backup时背后发生了以下四个关键步骤提交 Backup 对象Velero 客户端调用 Kubernetes API Server创建一个Backup自定义资源控制器校验BackupController监听watch到新的Backup对象后对其进行校验收集数据BackupController开始备份流程通过查询 API Server 收集需要备份的资源数据上传存储BackupController调用对象存储服务例如 AWS S3上传备份文件。整个流程对应下图图片左侧展示了用户通过 Velero CLI 提交velero backup create test-backup --snapshot-volumes请求中间部分是BackupController通过 Kubernetes API 监听/查询资源右侧则是与云服务商cloud provider交互完成备份文件上传与磁盘快照创建。在控制器实现层面pkg/controller/backup_controller.go中定义的backupReconciler承担了监听、校验和执行备份的核心职责其resyncBackupMetrics等辅助逻辑见 backup_controller.go还负责在控制器重同步时校正备份指标。关于卷快照默认情况下velero backup create会为备份中包含的持久卷制作磁盘快照你可以通过附加标志调整行为。运行velero backup create --help可查看全部可用标志。其中最常用的一个参数是velero backup create test-backup --snapshot-volumesfalse即显式关闭卷快照——适合只想备份 Kubernetes 对象元数据、不需要复制卷数据的场景。该开关在BackupSpec.SnapshotVolumes字段中有直接对应见 backup_types.go。备份使用的 API 版本Backed-up API VersionsVelero 在备份资源时使用 Kubernetes API Server 对每个 group/resource 的**首选版本preferred version**进行采集。相应地在目标集群恢复该资源时相同的 API group/version 必须存在恢复才能成功。官方文档给出了一个非常直观的例子假设被备份的集群中存在thingsAPI group 下的gizmos资源其 group/version 依次为things/v1alpha1、things/v1beta1和things/v1而服务端首选版本是things/v1那么所有gizmos对象都会从things/v1端点被备份。当从这个集群的备份进行恢复时目标集群必须具备things/v1端点才能成功恢复gizmos。注意things/v1不需要是目标集群的首选版本它只需存在即可。这一按首选版本备份、按存在版本恢复的语义决定了跨集群迁移尤其是源集群与目标集群 Kubernetes 版本或 API 演进进度不一致时必须提前核对目标集群的 API 支持情况。设置备份过期时间TTL创建备份时可以通过--ttl DURATION标志指定备份的保留时长。一旦 Velero 发现某个已存在的备份资源过期它会自动清理与该备份关联的以下全部内容Backup资源本身云对象存储中的备份文件所有 PersistentVolume 快照所有关联的Restore资源。TTL字段类型为metav1.Duration即一个可被time.Duration解析的字符串见 backup_types.go例如720h30 天。TTL 机制的工程意义在于它让备份生命周期管理完全自动化——无需人工定时清理过期备份存储成本也会被控制在合理范围内。对象存储同步Object Storage Sync以对象存储为唯一事实来源Velero 的一个核心理念是对象存储object storage是唯一事实来源source of truth。Velero 会持续检查存储桶确保正确的备份资源始终存在于 Kubernetes 集群中如果存储桶中存在格式正确的备份文件但 Kubernetes API 中没有对应的Backup资源Velero 会将信息从对象存储同步到 Kubernetes反之如果Backup对象存在于 Kubernetes 但对应的备份 tarball 已不在对象存储中则该Backup对象会从 Kubernetes 中被删除。这一机制的实现主体是pkg/controller/backup_sync_controller.go中的backupSyncReconciler见 backup_sync_controller.go它会周期性扫描对象存储并反哺集群内的备份资源视图。对象存储同步带来的直接价值是在集群迁移场景下恢复功能依然可用——即便新集群中不存在原始的备份对象只要对象存储中仍有备份文件Velero 就能自动重建对应的Backup资源随后执行恢复。这构成了跨集群迁移与灾难恢复的数据基础。补充一点对象存储同步的频率等行为由BackupStorageLocationSpec中的BackupSyncPeriod定义对象存储到 API 的同步周期设为 0 可禁用同步与ValidationFrequency定义存储位置校验周期控制见 backupstoragelocation_types.go这两个字段支持细粒度运维调优。实践要点小结操作即资源备份、定时备份、恢复都是 CRD 控制器模式既可用veleroCLI 操作也可直接使用kubectl管理对应自定义资源筛选三要素类型resource、命名空间namespace、标签label组合出灵活的备份/恢复边界恢复阶段还支持多命名空间重映射备份非原子对一致性有强要求的应用建议结合 hooks 在快照前完成数据 flush快照默认开启不需要卷数据时记得用--snapshot-volumesfalse关闭节省成本TTL 自动化清理为每个备份设置合理 TTL避免过期数据长期占用存储对象存储即真相备份文件在对象存储中的存在与否直接决定Backup资源能否在集群中存活理解这一点对设计灾备与迁移方案至关重要。若需要进一步了解实际部署步骤安装、存储位置配置、首次备份演练可继续阅读同目录下的 install-overview.md、locations.md 与 get-started.md。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考