Velero 工作原理深度解析以 Kubernetes CRD 为基石的备份、定时备份与恢复机制【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero本文以 Velero 官方文档「How Velero Works」为核心系统讲解 Velero 将每次备份、定时备份与恢复操作建模为 Kubernetes 自定义资源CRD并交由控制器驱动执行的架构原理涵盖按需备份、Cron 定时调度、多命名空间重映射恢复、对象存储同步与 TTL 过期清理等核心机制。读完本文你将掌握 Velero 备份/恢复全链路的工作流程、关键参数的作用与源码级实现依据能够在集群迁移、灾难恢复与应用升级前快照等场景中正确设计与使用 Velero。一、核心架构每个操作都是一个 Kubernetes 自定义资源Velero 的架构设计可以用一句话概括每一次操作——按需备份、定时备份、恢复——都是一个自定义资源Custom Resource由 Kubernetes CRD 机制定义并存储在 etcd 中。Velero 同时包含一组控制器Controller负责处理这些自定义资源从而真正执行备份、恢复以及所有相关操作。从当前仓库源码可以印证这一设计Velero 在 pkg/apis/velero/v1 下定义了BackupSpec、ScheduleSpec、RestoreSpec等核心类型其中 backup_types.go 中的BackupSpec包含IncludedNamespaces、ExcludedNamespaces、IncludedResources、ExcludedResources、LabelSelector、TTL等字段schedule_types.go 中的ScheduleSpec则内嵌了Template BackupSpec、Cron 表达式字段Schedule与Paused等控制字段。控制器侧的实现集中在 pkg/controller 目录例如backup_controller.go、schedule_controller.go、restore_controller.go、backup_sync_controller.go等它们各自监听对应的 CRD 事件并驱动实际工作。这一「声明式 控制器」架构带来两个直接好处可过滤备份范围你可以备份集群中的全部对象也可以按资源类型type、命名空间namespace和/或标签label进行过滤对应到BackupSpec中的 include/exclude 系列字段与LabelSelector。适用场景明确Velero 非常适合**灾难恢复disaster recovery**场景也可以在集群执行系统操作例如升级之前对应用状态进行快照保存。二、按需备份On-demand backups按需备份即通过velero backup create触发的backup操作它主要完成两件事将复制的 Kubernetes 对象打包成 tarball 并上传到云对象存储如 AWS S3如果指定了相关选项调用云厂商 API 为持久卷PersistentVolume创建磁盘快照。2.1 备份钩子Hooks在备份过程中你还可以通过**钩子hooks**指定在特定时刻执行的命令。最典型的场景是数据库在快照前需要先把内存缓冲 flush 到磁盘以保证数据一致性。关于 hooks 的完整配置说明见 hooks.md。Hooks 分为两种时机pre hook在该 Pod 执行自定义动作custom action处理之前执行post hook在所有自定义动作完成、且自定义动作指定的附加条目均已备份之后执行。注意 hooks不是在容器的 shell 中执行的。钩子可通过两种方式指定Pod 上的注解annotation或 Backup spec 中。注解方式支持以下键pre/post 各有一套同名键注解键说明pre.hook.backup.velero.io/container/post.hook.backup.velero.io/container执行命令的容器默认取 Pod 第一个容器可选pre.hook.backup.velero.io/command/post.hook.backup.velero.io/command要执行的命令多参数时使用 JSON 数组如[/usr/bin/uname, -a]pre.hook.backup.velero.io/on-error/post.hook.backup.velero.io/on-error命令返回非零退出码时的处理方式默认Fail可选值Fail与Continuepre.hook.backup.velero.io/timeout/post.hook.backup.velero.io/timeout等待命令执行的最长时间超时视为钩子错误默认30s一个使用fsfreeze冻结/解冻文件系统的完整示例基于 examples/nginx-app/with-pv.yaml如下kubectl annotate pod -n nginx-example -l appnginx \ pre.hook.backup.velero.io/command[/sbin/fsfreeze, --freeze, /var/log/nginx] \ pre.hook.backup.velero.io/containerfsfreeze \ post.hook.backup.velero.io/command[/sbin/fsfreeze, --unfreeze, /var/log/nginx] \ post.hook.backup.velero.io/containerfsfreeze随后创建备份并通过 Velero 日志验证钩子执行情况velero backup create nginx-hook-test velero backup get nginx-hook-test velero backup logs nginx-hook-test | grep hookCommand2.2 非原子性说明需要特别强调的是集群备份并非严格原子atomic。如果备份发生时 Kubernetes 对象正在被创建或编辑这些对象可能不会被包含进备份。捕获到不一致信息的概率很低但确实存在这种可能。因此对于要求强一致性的工作负载应结合上述 pre hook如fsfreeze冻结文件系统来尽量保证数据一致性。三、定时备份Scheduled backupsschedule操作允许你按固定间隔重复备份数据。其行为特征如下首次备份在 schedule 创建时立即执行后续备份按 schedule 指定的间隔执行间隔通过Cron 表达式指定。从源码看schedule_types.go 中ScheduleSpec.Schedule字段正是 Cron 表达式且Template字段内嵌完整BackupSpec意味着你可以为定时备份指定与手动备份完全一致的过滤、快照与 TTL 参数Paused字段可用于暂停调度。定时备份的命名规则为SCHEDULE NAME-TIMESTAMP其中TIMESTAMP的格式为YYYYMMDDhhmmss例如daily-backup-20260916150000。这种命名方式保证了同一 schedule 产生的备份名称唯一且按时间可排序。四、恢复Restoresrestore操作允许你从之前创建的备份中恢复全部对象与持久卷也可以只恢复经过过滤的对象的子集与对应持久卷。4.1 多命名空间重映射Velero 支持多命名空间重映射multiple namespace remapping在单次恢复中命名空间abc下的对象可以被重建到def命名空间下同时123命名空间下的对象被映射到456命名空间。这一能力在集群迁移、环境复制等场景中尤其有用。4.2 命名规则与标签恢复的默认名称格式为BACKUP NAME-TIMESTAMPTIMESTAMP同样采用YYYYMMDDhhmmss格式你也可以指定自定义名称每个被恢复的对象都会附带一个标签键为velero.io/restore-name值为RESTORE NAME便于追溯对象来源。这一标签在源码 labels_annotations.go 中有对应的常量定义。4.3 恢复专用模式restore-only你还可以让 Velero server 以restore-only 模式运行该模式会在灾难恢复期间**禁用备份backup、定时备份schedule与垃圾回收garbage collection**功能只保留恢复能力避免恢复过程中发生干扰。五、备份工作流程Backup Workflow当你执行velero backup create test-backup时背后发生如下 4 个步骤创建 Backup 对象Velero 客户端调用 Kubernetes API server创建一个Backup对象校验BackupController发现新的Backup对象并执行校验validation收集数据BackupController开始备份流程通过查询 API server 收集需要备份的资源数据上传对象存储BackupController调用对象存储服务例如 AWS S3上传备份文件tarball。这一「客户端创建对象 → 控制器响应处理 → 上传对象存储」的流程正是第一节所述声明式架构的具体体现。控制器对Backup对象的状态机处理validation、in-progress、completed/failed 等阶段可以在 pkg/controller/backup_controller.go 中追踪。5.1 关于持久卷快照默认情况下velero backup create会为所有持久卷创建磁盘快照。你可以通过附加标志来调整快照行为运行velero backup create --help查看全部可用标志使用--snapshot-volumesfalse可以禁用快照例如当持久卷数据已由外部存储复制、或仅需备份对象元数据时。对应的开关在BackupSpec的SnapshotVolumes字段中定义见 backup_types.go控制器在备份执行时会据此决定是否调用云厂商快照 API。六、备份的 API 版本Backed-up API VersionsVelero 备份资源时使用的是 Kubernetes API server 对每个 group/resource 的首选版本preferred version。恢复该资源时目标集群中必须存在相同的 API group/version恢复才能成功。举例说明假设被备份集群中有一个thingsAPI group 下的gizmos资源该 group 下存在things/v1alpha1、things/v1beta1、things/v1三个版本若服务器首选 group/version 是things/v1则所有gizmos都会从things/v1API 端点备份当从该集群的备份进行恢复时目标集群必须提供things/v1端点gizmos才能被恢复注意things/v1不需要是目标集群的首选版本它只需要存在即可。这一设计意味着在跨集群恢复尤其是跨 Kubernetes 小版本迁移时需要提前确认目标集群已安装对应的 API 版本否则恢复会失败。七、设置备份过期Set a Backup to Expire创建备份时你可以通过--ttl DURATION标志指定一个 TTL生存时间。源码层面对应BackupSpec.TTL字段其类型为metav1.Duration即一个可被time.Duration解析的字符串见 backup_types.go。当 Velero 发现一个已存在的备份资源过期时会清理以下内容备份资源Backup 资源本身对象存储中的备份文件cloud object storage 中的 tarball所有 PersistentVolume 快照所有关联的 Restorerestore 对象。TTL 机制配合后续章节的对象存储同步构成了 Velero 备份生命周期管理的闭环备份按计划创建、按 TTL 过期、过期后被自动清理避免对象存储无限增长。八、对象存储同步Object Storage SyncVelero 将对象存储视为数据真相的来源source of truth并持续检查以确保正确的备份资源始终存在。其同步逻辑如下存储桶中存在格式正确的备份文件、但 Kubernetes API 中没有对应备份资源时Velero 会把对象存储中的信息同步回 Kubernetes创建对应的备份资源Kubernetes 中存在备份对象、但对象存储中不存在时由于备份 tarball 已不存在该备份对象会从 Kubernetes 中被删除。这一双向同步机制使恢复功能在集群迁移场景中依然可用即使原集群中的备份对象在新集群中不存在只要对象存储桶中还有备份文件新集群中的 Velero 就能把这些信息同步回 Kubernetes从而允许执行恢复。该逻辑由 pkg/controller/backup_sync_controller.go 实现。九、小结与延伸阅读总结本文核心要点机制关键行为声明式模型备份/定时备份/恢复均为 CRD存储于 etcd由控制器驱动执行按需备份上传 Kubernetes 对象 tarball 至对象存储可选持久卷磁盘快照与 pre/post hooks定时备份Cron 表达式调度首备份立即执行命名SCHEDULE-TIMESTAMP恢复支持过滤与多命名空间重映射对象打velero.io/restore-name标签可运行 restore-only 模式备份版本使用 API server 首选版本备份目标集群须存在对应 group/versionTTL--ttl DURATION控制过期过期后清理备份资源、备份文件、快照与关联 Restore对象存储同步对象存储为 source of truth双向同步保证集群迁移后可恢复如需继续深入可在本仓库中阅读hooks.md备份钩子的完整配置指南与 fsfreeze 实战示例api-types/backup.mdBackup API 类型的字段级文档pkg/apis/velero/v1/backup_types.goBackupSpec全部字段定义include/exclude、LabelSelector、TTL 等pkg/apis/velero/v1/schedule_types.goScheduleSpec的 Cron 与 Template 定义pkg/controller/backup_controller.go 与 pkg/controller/backup_sync_controller.go备份执行与对象存储同步的控制器实现。掌握上述机制后无论是日常的升级前快照、跨环境数据迁移还是完整的灾难恢复演练你都能准确预期 Velero 的行为并针对数据一致性与 API 版本兼容性提前做好规划。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Velero 工作原理深度解析：以 Kubernetes CRD 为基石的备份、定时备份与恢复机制
Velero 工作原理深度解析以 Kubernetes CRD 为基石的备份、定时备份与恢复机制【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero本文以 Velero 官方文档「How Velero Works」为核心系统讲解 Velero 将每次备份、定时备份与恢复操作建模为 Kubernetes 自定义资源CRD并交由控制器驱动执行的架构原理涵盖按需备份、Cron 定时调度、多命名空间重映射恢复、对象存储同步与 TTL 过期清理等核心机制。读完本文你将掌握 Velero 备份/恢复全链路的工作流程、关键参数的作用与源码级实现依据能够在集群迁移、灾难恢复与应用升级前快照等场景中正确设计与使用 Velero。一、核心架构每个操作都是一个 Kubernetes 自定义资源Velero 的架构设计可以用一句话概括每一次操作——按需备份、定时备份、恢复——都是一个自定义资源Custom Resource由 Kubernetes CRD 机制定义并存储在 etcd 中。Velero 同时包含一组控制器Controller负责处理这些自定义资源从而真正执行备份、恢复以及所有相关操作。从当前仓库源码可以印证这一设计Velero 在 pkg/apis/velero/v1 下定义了BackupSpec、ScheduleSpec、RestoreSpec等核心类型其中 backup_types.go 中的BackupSpec包含IncludedNamespaces、ExcludedNamespaces、IncludedResources、ExcludedResources、LabelSelector、TTL等字段schedule_types.go 中的ScheduleSpec则内嵌了Template BackupSpec、Cron 表达式字段Schedule与Paused等控制字段。控制器侧的实现集中在 pkg/controller 目录例如backup_controller.go、schedule_controller.go、restore_controller.go、backup_sync_controller.go等它们各自监听对应的 CRD 事件并驱动实际工作。这一「声明式 控制器」架构带来两个直接好处可过滤备份范围你可以备份集群中的全部对象也可以按资源类型type、命名空间namespace和/或标签label进行过滤对应到BackupSpec中的 include/exclude 系列字段与LabelSelector。适用场景明确Velero 非常适合**灾难恢复disaster recovery**场景也可以在集群执行系统操作例如升级之前对应用状态进行快照保存。二、按需备份On-demand backups按需备份即通过velero backup create触发的backup操作它主要完成两件事将复制的 Kubernetes 对象打包成 tarball 并上传到云对象存储如 AWS S3如果指定了相关选项调用云厂商 API 为持久卷PersistentVolume创建磁盘快照。2.1 备份钩子Hooks在备份过程中你还可以通过**钩子hooks**指定在特定时刻执行的命令。最典型的场景是数据库在快照前需要先把内存缓冲 flush 到磁盘以保证数据一致性。关于 hooks 的完整配置说明见 hooks.md。Hooks 分为两种时机pre hook在该 Pod 执行自定义动作custom action处理之前执行post hook在所有自定义动作完成、且自定义动作指定的附加条目均已备份之后执行。注意 hooks不是在容器的 shell 中执行的。钩子可通过两种方式指定Pod 上的注解annotation或 Backup spec 中。注解方式支持以下键pre/post 各有一套同名键注解键说明pre.hook.backup.velero.io/container/post.hook.backup.velero.io/container执行命令的容器默认取 Pod 第一个容器可选pre.hook.backup.velero.io/command/post.hook.backup.velero.io/command要执行的命令多参数时使用 JSON 数组如[/usr/bin/uname, -a]pre.hook.backup.velero.io/on-error/post.hook.backup.velero.io/on-error命令返回非零退出码时的处理方式默认Fail可选值Fail与Continuepre.hook.backup.velero.io/timeout/post.hook.backup.velero.io/timeout等待命令执行的最长时间超时视为钩子错误默认30s一个使用fsfreeze冻结/解冻文件系统的完整示例基于 examples/nginx-app/with-pv.yaml如下kubectl annotate pod -n nginx-example -l appnginx \ pre.hook.backup.velero.io/command[/sbin/fsfreeze, --freeze, /var/log/nginx] \ pre.hook.backup.velero.io/containerfsfreeze \ post.hook.backup.velero.io/command[/sbin/fsfreeze, --unfreeze, /var/log/nginx] \ post.hook.backup.velero.io/containerfsfreeze随后创建备份并通过 Velero 日志验证钩子执行情况velero backup create nginx-hook-test velero backup get nginx-hook-test velero backup logs nginx-hook-test | grep hookCommand2.2 非原子性说明需要特别强调的是集群备份并非严格原子atomic。如果备份发生时 Kubernetes 对象正在被创建或编辑这些对象可能不会被包含进备份。捕获到不一致信息的概率很低但确实存在这种可能。因此对于要求强一致性的工作负载应结合上述 pre hook如fsfreeze冻结文件系统来尽量保证数据一致性。三、定时备份Scheduled backupsschedule操作允许你按固定间隔重复备份数据。其行为特征如下首次备份在 schedule 创建时立即执行后续备份按 schedule 指定的间隔执行间隔通过Cron 表达式指定。从源码看schedule_types.go 中ScheduleSpec.Schedule字段正是 Cron 表达式且Template字段内嵌完整BackupSpec意味着你可以为定时备份指定与手动备份完全一致的过滤、快照与 TTL 参数Paused字段可用于暂停调度。定时备份的命名规则为SCHEDULE NAME-TIMESTAMP其中TIMESTAMP的格式为YYYYMMDDhhmmss例如daily-backup-20260916150000。这种命名方式保证了同一 schedule 产生的备份名称唯一且按时间可排序。四、恢复Restoresrestore操作允许你从之前创建的备份中恢复全部对象与持久卷也可以只恢复经过过滤的对象的子集与对应持久卷。4.1 多命名空间重映射Velero 支持多命名空间重映射multiple namespace remapping在单次恢复中命名空间abc下的对象可以被重建到def命名空间下同时123命名空间下的对象被映射到456命名空间。这一能力在集群迁移、环境复制等场景中尤其有用。4.2 命名规则与标签恢复的默认名称格式为BACKUP NAME-TIMESTAMPTIMESTAMP同样采用YYYYMMDDhhmmss格式你也可以指定自定义名称每个被恢复的对象都会附带一个标签键为velero.io/restore-name值为RESTORE NAME便于追溯对象来源。这一标签在源码 labels_annotations.go 中有对应的常量定义。4.3 恢复专用模式restore-only你还可以让 Velero server 以restore-only 模式运行该模式会在灾难恢复期间**禁用备份backup、定时备份schedule与垃圾回收garbage collection**功能只保留恢复能力避免恢复过程中发生干扰。五、备份工作流程Backup Workflow当你执行velero backup create test-backup时背后发生如下 4 个步骤创建 Backup 对象Velero 客户端调用 Kubernetes API server创建一个Backup对象校验BackupController发现新的Backup对象并执行校验validation收集数据BackupController开始备份流程通过查询 API server 收集需要备份的资源数据上传对象存储BackupController调用对象存储服务例如 AWS S3上传备份文件tarball。这一「客户端创建对象 → 控制器响应处理 → 上传对象存储」的流程正是第一节所述声明式架构的具体体现。控制器对Backup对象的状态机处理validation、in-progress、completed/failed 等阶段可以在 pkg/controller/backup_controller.go 中追踪。5.1 关于持久卷快照默认情况下velero backup create会为所有持久卷创建磁盘快照。你可以通过附加标志来调整快照行为运行velero backup create --help查看全部可用标志使用--snapshot-volumesfalse可以禁用快照例如当持久卷数据已由外部存储复制、或仅需备份对象元数据时。对应的开关在BackupSpec的SnapshotVolumes字段中定义见 backup_types.go控制器在备份执行时会据此决定是否调用云厂商快照 API。六、备份的 API 版本Backed-up API VersionsVelero 备份资源时使用的是 Kubernetes API server 对每个 group/resource 的首选版本preferred version。恢复该资源时目标集群中必须存在相同的 API group/version恢复才能成功。举例说明假设被备份集群中有一个thingsAPI group 下的gizmos资源该 group 下存在things/v1alpha1、things/v1beta1、things/v1三个版本若服务器首选 group/version 是things/v1则所有gizmos都会从things/v1API 端点备份当从该集群的备份进行恢复时目标集群必须提供things/v1端点gizmos才能被恢复注意things/v1不需要是目标集群的首选版本它只需要存在即可。这一设计意味着在跨集群恢复尤其是跨 Kubernetes 小版本迁移时需要提前确认目标集群已安装对应的 API 版本否则恢复会失败。七、设置备份过期Set a Backup to Expire创建备份时你可以通过--ttl DURATION标志指定一个 TTL生存时间。源码层面对应BackupSpec.TTL字段其类型为metav1.Duration即一个可被time.Duration解析的字符串见 backup_types.go。当 Velero 发现一个已存在的备份资源过期时会清理以下内容备份资源Backup 资源本身对象存储中的备份文件cloud object storage 中的 tarball所有 PersistentVolume 快照所有关联的 Restorerestore 对象。TTL 机制配合后续章节的对象存储同步构成了 Velero 备份生命周期管理的闭环备份按计划创建、按 TTL 过期、过期后被自动清理避免对象存储无限增长。八、对象存储同步Object Storage SyncVelero 将对象存储视为数据真相的来源source of truth并持续检查以确保正确的备份资源始终存在。其同步逻辑如下存储桶中存在格式正确的备份文件、但 Kubernetes API 中没有对应备份资源时Velero 会把对象存储中的信息同步回 Kubernetes创建对应的备份资源Kubernetes 中存在备份对象、但对象存储中不存在时由于备份 tarball 已不存在该备份对象会从 Kubernetes 中被删除。这一双向同步机制使恢复功能在集群迁移场景中依然可用即使原集群中的备份对象在新集群中不存在只要对象存储桶中还有备份文件新集群中的 Velero 就能把这些信息同步回 Kubernetes从而允许执行恢复。该逻辑由 pkg/controller/backup_sync_controller.go 实现。九、小结与延伸阅读总结本文核心要点机制关键行为声明式模型备份/定时备份/恢复均为 CRD存储于 etcd由控制器驱动执行按需备份上传 Kubernetes 对象 tarball 至对象存储可选持久卷磁盘快照与 pre/post hooks定时备份Cron 表达式调度首备份立即执行命名SCHEDULE-TIMESTAMP恢复支持过滤与多命名空间重映射对象打velero.io/restore-name标签可运行 restore-only 模式备份版本使用 API server 首选版本备份目标集群须存在对应 group/versionTTL--ttl DURATION控制过期过期后清理备份资源、备份文件、快照与关联 Restore对象存储同步对象存储为 source of truth双向同步保证集群迁移后可恢复如需继续深入可在本仓库中阅读hooks.md备份钩子的完整配置指南与 fsfreeze 实战示例api-types/backup.mdBackup API 类型的字段级文档pkg/apis/velero/v1/backup_types.goBackupSpec全部字段定义include/exclude、LabelSelector、TTL 等pkg/apis/velero/v1/schedule_types.goScheduleSpec的 Cron 与 Template 定义pkg/controller/backup_controller.go 与 pkg/controller/backup_sync_controller.go备份执行与对象存储同步的控制器实现。掌握上述机制后无论是日常的升级前快照、跨环境数据迁移还是完整的灾难恢复演练你都能准确预期 Velero 的行为并针对数据一致性与 API 版本兼容性提前做好规划。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考