Velero v1.11 备份配置参考排除项、资源备份顺序、定时备份、API 分页与备份删除机制【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero本篇技术指南基于 Velero v1.11 的官方备份参考文档整理覆盖备份流程中五类高频配置与操作通过标签排除特定资源、使用--ordered-resources指定同类资源的备份顺序、基于 Cron 表达式创建定时备份、Kubernetes API LIST 分页调优以及两种删除备份的方式与区别。读完后你将能够针对真实集群完成精细化的备份策略配置理解每个配置项在 Velero 源码中的落地位置并规避 OwnerReference 与对象存储不可变immutability两类已知的边界问题。从备份 Spec 中排除特定资源即使某个资源匹配了备份 spec 中定义的资源、命名空间或标签选择器仍然可以将其单独排除。做法是为该资源打上velero.io/exclude-from-backuptrue标签kubectl label -n ITEM_NAMESPACE RESOURCE/NAME velero.io/exclude-from-backuptrue该标签在源码中的定义位于 labels_annotations.goExcludeFromBackupLabel velero.io/exclude-from-backup实际生效逻辑在备份执行阶段的 item_backupper.goif metadata.GetLabels()[velerov1api.ExcludeFromBackupLabel] true { log.Infof(Excluding item because it has label %strue, velerov1api.ExcludeFromBackupLabel) ... }从源码结构看有三个值得注意的细节只有值精确为字符串true才生效。backup_test.go 中的测试用例明确验证了标签值为false、1或空字符串的资源仍会被备份该标签的优先级高于选择器匹配。item_backupper_test.go 中的测试验证了exclude-from-backuptrue会优先于命名空间过滤策略、通配过滤策略以及集群级过滤策略即使资源被这些策略显式包含也会被排除标签同样作用于插件返回的附加关联项additional/related items。backup_test.go 中存在带该标签的附加项不被备份的测试场景说明排除逻辑覆盖备份收集后的关联资源阶段。此外在备份请求构造阶段还有第二层排除机制backup_controller.go 会把所有带velero.io/exclude-from-backuptrue标签的命名空间追加到request.Spec.ExcludedNamespaces中其语义等价于在备份 spec 里直接设置spec.ExcludedNamespaces——也就是说给整个命名空间打这个标签可以批量排除该命名空间下的全部资源而不必逐项标注。该行为还有一条端到端测试用例佐证e2e_suite_test.goResources with the label velero.io/exclude-from-backuptrue are not included in backup。指定特定 Kind 资源的备份顺序默认情况下Velero 备份各资源类型的内部顺序是不确定的。如果需要让特定 Kind 的资源按指定顺序先行备份可以使用--ordered-resources选项它接收一个Kind 到该 Kind 下有序资源名列表的映射资源名之间用逗号分隔格式为namespace/resourcename集群级资源cluster-scoped直接写资源名即可映射的键值对之间用分号分隔Kind 名称使用复数形式即资源名如pods、persistentvolumes。官方文档给出的两个示例velero backup create backupName --include-cluster-resourcestrue --ordered-resources podsns1/pod1,ns1/pod2;persistentvolumespv4,pv8 --include-namespacesns1 velero backup create backupName --ordered-resources statefulsetsns1/sts1,ns1/sts0 --include-namespacesns1该标志的定义在 CLI 源码 create.go 中其帮助文本与上述规则一致。CLI 侧的解析函数 ParseOrderedResources 按;切分键值对、按切分 Kind 与资源列表、按,切分资源名并对每段做TrimSpace清洗因此pods ns1/p1,ns1/p2 ; persistentvolumeclaimsns2/pvc1这类带空格写法也能被正确解析create_test.go 有对应测试任意一段不满足kindnames结构都会报invalid OrderedResources错误。服务端排序逻辑在 item_collector.gogetOrderedResourcesForType按资源类型资源名即 Kind 复数形式取出对应的顺序列表sortGroupItems则先从全部已收集项中按列表顺序挑出指定的资源并标记orderedResource true列表中找不到某资源名时仅输出Cannot find resource %s.的警告而非报错最后再把剩余资源按原有顺序追加在后。即指定顺序的资源排在最前未指定的资源保持原相对顺序且顺序只作用于被点名的资源不影响同 Kind 下其他资源。端到端验证可参考 test/e2e/schedule/ordered_resources.go该用例覆盖了通过 Schedule 模板下发有序资源的场景。创建定时备份Scheduleschedule操作允许你基于 Cron 表达式在指定时间周期性创建备份velero schedule create NAME --schedule* * * * * [flags]Cron 表达式共五个字段格式如下分钟、小时、日、月、星期# ┌───────────── minute (0 - 59) # │ ┌───────────── hour (0 - 23) # │ │ ┌───────────── day of the month (1 - 31) # │ │ │ ┌───────────── month (1 - 12) # │ │ │ │ ┌───────────── day of the week (0 - 6) (Sunday to Saturday; # │ │ │ │ │ 7 is also Sunday on some systems) # │ │ │ │ │ # * * * * *例如下面的命令创建一个每天凌晨 3 点执行的备份任务velero schedule create example-schedule --schedule0 3 * * *这条命令会在 Velero 中创建名为example-schedule的备份模板但备份要等到下一个调度时间点凌晨 3 点才真正执行。由 Schedule 创建的备份命名为SCHEDULE NAME-TIMESTAMP其中TIMESTAMP的格式为YYYYMMDDhhmmss——这与源码 schedule_types.go 中的命名实现一致timestamp.Format(20060102150405)。Schedule 对象本身的核心字段定义见 schedule_types.goTemplate备份模板即BackupSpec、ScheduleCron 表达式、UseOwnerReferencesInBackup、Paused以及SkipImmediately控制暂停恢复或新建调度时是否立即跳过到下一个调度点。查看所有可用配置标志velero schedule create --help创建调度后可以随时手动触发一次备份而不影响原有调度计划velero backup create --from-schedule example-schedule该命令会基于example-schedule的模板立即创建一次新备份不会改变调度本身下一次备份仍会在计划时间点触发。从 CLI 源码看--from-schedule标志在 create.go 中单独绑定帮助文本明确不能与其他过滤参数同时使用且指定后备份名可省略create_test.go 还验证了值为空字符串或纯空格时会报flag must have a non-empty value: --from-schedule错误。备份名省略时由 Velero 自动生成同样是schedule名-时间戳形式见 create.go 中对时间戳后缀长度 15 的处理。限制与边界1. 备份与 Schedule 的 OwnerReference 关联通过--use-owner-references-in-backup可以让 Schedule 成为其创建备份的 Ownervelero schedule create --use-owner-references-in-backup backup-name启用后 Schedule 是这些备份的 owner适用于某些 GitOps 场景或从其他位置同步 Kubernetes 资源树的场景。对应的 API 字段为 ScheduleSpec.UseOwnerReferencesInBackup*bool可选CLI 帮助文本见 schedule/create.go其明确警告设为 true 时删除 schedule 会连带删除备份备份构造侧的实现见 backup_builder.go。但文档特别强调了一个可能出乎预期的副作用由于 Schedule 是 owner删除 Schedule 时Kubernetes GC 控制器会连带删除关联的备份 CR注意对象存储中的备份数据与卷快照本身不会被删。而 Velero 控制器又会从对象存储的元数据中把这些备份重新同步回集群于是 K8s GC 控制器与 Velero 控制器会就这些备份应该存在还是不存在持续相互对抗。因此如果存在调度可能被停用、不再创建新备份但已有备份仍然有用的情况不要启用该选项。此问题对应 Velero 上游 issue #4093Backups created by a schedule with useOwnerReferenceInBackup set do not get synced properly。2. 不支持对象存储的备份数据不可变性immutability从 1.11 版本开始当目标对象存储配置了某种immutability选项不同厂商叫法不同时Velero 的备份可能无法按预期工作。根本原因在于备份收尾流程Velero 先把备份状态保存为Finalizing然后检查是否有异步操作async operations在进行中——如果有需等待全部完成后才将状态置为 Complete如果没有异步操作则立即置为 Complete。无论哪种路径Velero 都需要修改对象存储中的备份元数据而一旦对象存储配置了不可变性这种修改就会失败。文档同时指出即便在 1.11 之前的版本Velero 也从未显式支持带 immutability 配置的对象存储因此即便备份看似正常工作也可能存在隐患例如删除备份时部分versions对象未被清理。不同云厂商的具体差异如下源自各厂商官方文档仓库中不附外部链接AWS S3备份可以工作因为 S3 的 Object Lock 只作用于版本化桶versioned buckets对象数据仍可更新为新版本但删除备份时对象的旧版本不会被删除。Azure Storage Blob同时支持版本级version-level与容器级container-level不可变性。版本级场景下数据不可变性在 Velero 中仍可工作容器级则不行。GCP Cloud Storage仅支持桶级bucket-level不可变性因此在 GCP 环境下没有可行的工作方式。Kubernetes API 分页收集备份项时Velero 默认对每个资源类型的 Kubernetes API LIST 调用进行分页服务端启动参数--client-page-size控制每页大小。从服务端配置源码看config.go 与 config.go默认值为 500defaultClientPageSize int 500标志描述为Page size of requests by the server to the Kubernetes API when listing objects during a backup. Set to 0 to disable paging.取值必须非负server.go 中显式校验client-page-size must not be negative。根据集群规模调大或调小页大小都可能改善备份性能文档建议可以试验更大的值同时关注其对 apiserverapiserver_request_duration_seconds_*相关指标的影响。将--client-page-size设为0可以完全禁用分页此时 Velero 会在一次不分页的 LIST 调用中请求全部对象——适用于小规模集群追求更少的请求往返但大集群上会显著增加单次 LIST 的 apiserver 压力需要结合实际负载评估。删除备份CR 与数据的区别删除备份有两种命令语义完全不同务必区分命令效果kubectl delete backup backupName -n veleroNamespace仅删除备份 CR不删除对象存储/块存储中关联的任何备份数据velero backup delete backupName删除备份资源并连带删除对象存储/块存储中的全部备份数据从实现上看velero backup delete走的是 Velero 自身的异步删除协议CLI 在 delete.go 中构造DeleteBackupRequest对象提交给 Velero 控制器由控制器按 backup_deletion_controller.go 的流程清理对象存储中的归档、备份元数据及卷数据完成后才删除备份 CR。而kubectl delete backup直接作用于 CR绕过了这一清理流程因此对象存储里的数据会成为孤儿数据持续占用空间。如果只是想丢弃 CR 记录例如备份数据已由其他工具归档或确认无需保留可以用前者只要需要真正回收对象存储/块存储空间就必须使用velero backup delete。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考