云原生存储高可用容器编排【免费下载链接】longhornCloud-Native distributed storage built on and for Kubernetes项目地址https://gitcode.com/gh_mirrors/lo/longhorn点击查看免费下载导读Longhorn 的 RecurringJob定时任务机制在 v1.5.0 引入了两种专用于快照清理的新任务类型snapshot-delete与snapshot-cleanup用于解决非定时任务创建的快照无法自动回收的痛点。本文以 enhancements/20230103-recurring-snapshot-cleanup.md 为骨架结合当前仓库中的 CRD 定义、Helm 参数与演进文档完整讲解这两种任务的语义差异、YAML 配置方法、底层执行流程与验证方式帮助你为卷建立自动化的快照空间回收策略。背景与动机为什么需要快照清理型定时任务既有清理能力的局限Longhorn 的 RecurringJob 长期支持对快照的自动回收定时执行snapshot任务创建快照后会自动删除超过spec.retain定义数量的较旧快照。但这套清理逻辑存在一个明确边界——它只清理由该 RecurringJob 自己创建的快照。对于以下来源的快照用户此前只能手动删除手动非定时创建的卷快照备份流程中由 Longhorn 生成的快照卷操作过程中产生的系统快照如删除副本、在线扩容时生成的中间快照。上述快照如果长期堆积会持续占用备份存储或磁盘空间而用户缺少一个按保留数量统一回收所有来源快照的自动机制。这正是 issue #3836 提出的核心诉求也是 enhancements/20230103-recurring-snapshot-cleanup.md 的设计目标。设计目标该增强提案引入两个新的RecurringJobType任务类型行为保留语义snapshot-delete定期删除并 purge彻底清除超出保留数量的所有类型快照遵循spec.retain保留数量snapshot-cleanup定期 purge 可移除的系统快照不依赖spec.retain一律清除过期系统快照功能已在 Longhorn v1.5.0 正式发布见 CHANGELOG-1.5.0.md 中的 Snapshot Cleanup Delete Recurring Job 条目。两种任务类型的语义辨析snapshot-delete按保留数回收全部快照枚举卷上所有已过期快照无论其创建方式手动、定时、备份产生如何删除超出spec.retain数量的快照并对已标记删除的快照执行 purge彻底清除数据块与既有snapshot任务共用同一套过期判定 purge清理管线下文详述。snapshot-cleanup仅回收系统快照只针对可移除的或系统生成的快照如删除副本、在线扩容等操作留下的临时快照不删除用户手动创建的快照因此保留数量retain对该任务无实际作用——这正是设计文档中RecurringJob Mutate一节将spec.retain强制改写为 0 的原因。一句话区分snapshot-delete是全量按数保留snapshot-cleanup是定向清理系统残留。配置实战完整 YAML 示例两种任务均通过longhorn.io/v1beta2的RecurringJobCRD 声明唯一差异在spec.task字段。示例一snapshot-delete每分钟执行保留 2 个快照apiVersion: longhorn.io/v1beta2 kind: RecurringJob metadata: name: recurring-snap-delete-per-min namespace: longhorn-system spec: concurrency: 1 cron: * * * * * groups: [] labels: {} name: recurring-snap-delete-per-min retain: 2 task: snapshot-delete任务完成后卷上无论快照来源将只剩 2 个最新快照。示例二snapshot-cleanup每分钟执行apiVersion: longhorn.io/v1beta2 kind: RecurringJob metadata: name: recurring-snap-cleanup-per-min namespace: longhorn-system spec: concurrency: 1 cron: * * * * * groups: [] labels: {} name: recurring-snap-cleanup-per-min task: snapshot-cleanup任务完成后卷上的系统快照数量应为 0。注意此例中无需也不应依赖retain字段——CRD 校验与控制器会在该任务类型下将其按 0 处理。字段说明依据当前仓库 CRD 定义以上字段的语义可在 chart/templates/crds.yaml 的RecurringJobSpec中逐项核对字段类型说明concurrencyinteger每次触发的快照/备份操作的并发度cronstringCron 调度表达式如* * * * *表示每分钟groupsarray定时任务所属分组供卷通过分组标签批量引用labelsobject应用到生成快照/备份的标签retaininteger保留的快照/备份数量仅count-based保留策略下生效taskstring任务类型合法枚举见 CRDsnapshot、snapshot-force-create、snapshot-cleanup、snapshot-delete、backup、backup-force-create、filesystem-trim、system-backup另外当前 CRD 还提供了retentionPolicy默认count-based可选age-based与retainAgeGo duration 字符串如10m、24h、8760h字段实现基于快照/备份年龄的过期清理。需要留意的是age-based保留策略与snapshot-delete/snapshot-cleanup任务互斥校验会直接拒绝task: snapshot-delete配合retentionPolicy: age-based的组合详见 enhancements/20260819-age-based-retention-for-recurring-jobs.md 的约束表。将任务绑定到卷RecurringJob本身是集群级定义需要通过标签机制挂到具体卷或 StorageClass 上源自 label-driven recurring job 设计卷标签引用单个任务recurring-job.longhorn.io/JobName: enabled卷标签引用任务分组recurring-job-group.longhorn.io/GroupName: enabled任务处于default分组时会对没有配置任何任务标签的卷自动生效StorageClass 侧通过persistence.recurringJobSelector配置enable: true时以jobList指定任务名或分组名例如[{name:backup, isGroup:true}]见 chart/README.md。绑定完成后调度器会为每个 RecurringJob 生成对应的 Kubernetes CronJob按cron表达式周期触发。底层执行流程从源码设计看实现设计文档明确了两个任务的执行路径都收敛到同一套清理函数差异只在输入的快照清单。snapshot-delete 执行链枚举过期快照列出卷上所有已过期快照逻辑与既有listSnapshotNamesForCleanup实现一致构造清理清单将上述快照名作为cleanupSnapshotNames传入清理入口doSnapshotCleanup执行 purge沿用既有的 purge 实现将标记删除的快照数据彻底清除释放存储空间。snapshot-cleanup 执行链仅调用doSnapshotCleanup执行 purge 步骤且清理对象限定为系统/可移除快照——因此无需快照枚举与保留数比较retain无任何作用。RecurringJob Mutate 规则控制器的 mutate变更逻辑会在任务类型为snapshot-cleanup时将spec.retain强制改写为 0以避免用户误以为设置了保留数会影响清理结果。从源码结构看listSnapshotNamesForCleanup与doSnapshotCleanup是清理管线的核心构件两类任务通过复用同一 purge 流程保证了清理行为的一致性与可测试性。相关全局设置与空间管理快照清理并非孤立功能实际部署时可配合以下 Longhorn 全局设置均可在 chart/README.md 及 chart/questions.yaml 中配置recurringJobMaxRetention单个 RecurringJob 允许保留的快照/备份最大数量上限snapshotMaxCount卷允许的最大快照数量2250默认 100超出会触发TooManySnapshots卷条件告警与snapshotCountWarningThreshold配合使用autoCleanupRecurringJobBackupSnapshot是否自动清理由定时备份任务生成的快照allowRecurringJobWhileVolumeDetached卷处于分离状态时是否自动挂载以执行定时任务snapshotHeavyTaskConcurrentLimit每节点并发执行的快照重任务如 purge、clone数量上限清理任务同样受此限流保护。一个典型的空间治理组合是snapshot-deleteretain2负责兜底回收所有来源快照 snapshot-cleanup按天调度负责清扫系统残留 全局snapshotMaxCount作为最后防线。测试计划如何验证清理行为设计文档给出了两条可复现的验证路径适用于本地测试集群验证 snapshot-delete创建卷创建 2 个卷备份创建 2 个手动快照创建task: snapshot-delete的 RecurringJob保留数自定将任务绑定到卷等待定时任务完成检查卷上快照数量应恰好等于 RecurringJob 的spec.retain。验证 snapshot-cleanup创建卷制造 2 个系统快照例如删除一个副本、执行一次在线扩容创建task: snapshot-cleanup的 RecurringJob将任务绑定到卷等待定时任务完成检查卷上系统快照数量应为 0同时手动快照不受影响。演进与注意事项发布节点该能力随 v1.5.0 一并发布升级前请确认目标版本 ≥ v1.5.0与卷组快照的交互后续的卷组快照设计enhancements/20260811-volume-group-snapshot.md明确说明snapshot-delete的 retain 计数作用于卷上的每一个快照因此它可能将组内成员快照老化清除并导致快照组进入 Degraded 状态——这是刻意保留的硬性保留上限行为防止被遗忘的组拖住快照导致snapshot-max-count触顶后新快照创建失败与 age-based 策略的互斥snapshot-delete/snapshot-cleanup不接受age-based保留策略配置前请检查 RecurringJob 的retentionPolicy字段。总结snapshot-delete与snapshot-cleanup补齐了 Longhorn 定时任务在快照回收维度上的能力拼图前者以保留数为准绳统一回收所有来源快照后者定向清扫系统快照残留。结合卷标签绑定、StorageClass 选择器与全局空间阈值设置你可以将快照生命周期管理完全自动化避免手动清理的运维负担与空间浪费。赞分享云原生存储高可用容器编排【免费下载链接】longhornCloud-Native distributed storage built on and for Kubernetes项目地址https://gitcode.com/gh_mirrors/lo/longhorn点击查看免费下载相关推荐Device Mapper 快照支持snapshot / snapshot-origin / snapshot-merge内核机制与 LVM2 实战指南Device Mapper 快照支持snapshot / snapshot origin / snapshot merge内核机制与 LVM2 实战指南 D操作系统内核驱动驱动开发虚拟化嵌入式网络存储Longhorn 扩展 CSI Snapshot 支持集群内 Longhorn 快照设计原理、配置实战与验证指南Longhorn 扩展 CSI Snapshot 支持集群内 Longhorn 快照设计原理、配置实战与验证指南 本指南以 Longhorn 增强设计文档 e云原生存储高可用容器编排AVA Snapshot Workflow 实战移除快照断言时数据的清理与保留机制AVA Snapshot Workflow 实战移除快照断言时数据的清理与保留机制 导读 在 AVA 测试框架中快照snapshot文件与测试代码的生命测试上一篇o_proxy_server路径重写实战正则捕获组URL重写技巧与10个实用示例下一篇【免费下载】 Nunchaku项目安装与配置指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Longhorn 定时快照清理：snapshot-delete 与 snapshot-cleanup 任务类型实战指南
云原生存储高可用容器编排【免费下载链接】longhornCloud-Native distributed storage built on and for Kubernetes项目地址https://gitcode.com/gh_mirrors/lo/longhorn点击查看免费下载导读Longhorn 的 RecurringJob定时任务机制在 v1.5.0 引入了两种专用于快照清理的新任务类型snapshot-delete与snapshot-cleanup用于解决非定时任务创建的快照无法自动回收的痛点。本文以 enhancements/20230103-recurring-snapshot-cleanup.md 为骨架结合当前仓库中的 CRD 定义、Helm 参数与演进文档完整讲解这两种任务的语义差异、YAML 配置方法、底层执行流程与验证方式帮助你为卷建立自动化的快照空间回收策略。背景与动机为什么需要快照清理型定时任务既有清理能力的局限Longhorn 的 RecurringJob 长期支持对快照的自动回收定时执行snapshot任务创建快照后会自动删除超过spec.retain定义数量的较旧快照。但这套清理逻辑存在一个明确边界——它只清理由该 RecurringJob 自己创建的快照。对于以下来源的快照用户此前只能手动删除手动非定时创建的卷快照备份流程中由 Longhorn 生成的快照卷操作过程中产生的系统快照如删除副本、在线扩容时生成的中间快照。上述快照如果长期堆积会持续占用备份存储或磁盘空间而用户缺少一个按保留数量统一回收所有来源快照的自动机制。这正是 issue #3836 提出的核心诉求也是 enhancements/20230103-recurring-snapshot-cleanup.md 的设计目标。设计目标该增强提案引入两个新的RecurringJobType任务类型行为保留语义snapshot-delete定期删除并 purge彻底清除超出保留数量的所有类型快照遵循spec.retain保留数量snapshot-cleanup定期 purge 可移除的系统快照不依赖spec.retain一律清除过期系统快照功能已在 Longhorn v1.5.0 正式发布见 CHANGELOG-1.5.0.md 中的 Snapshot Cleanup Delete Recurring Job 条目。两种任务类型的语义辨析snapshot-delete按保留数回收全部快照枚举卷上所有已过期快照无论其创建方式手动、定时、备份产生如何删除超出spec.retain数量的快照并对已标记删除的快照执行 purge彻底清除数据块与既有snapshot任务共用同一套过期判定 purge清理管线下文详述。snapshot-cleanup仅回收系统快照只针对可移除的或系统生成的快照如删除副本、在线扩容等操作留下的临时快照不删除用户手动创建的快照因此保留数量retain对该任务无实际作用——这正是设计文档中RecurringJob Mutate一节将spec.retain强制改写为 0 的原因。一句话区分snapshot-delete是全量按数保留snapshot-cleanup是定向清理系统残留。配置实战完整 YAML 示例两种任务均通过longhorn.io/v1beta2的RecurringJobCRD 声明唯一差异在spec.task字段。示例一snapshot-delete每分钟执行保留 2 个快照apiVersion: longhorn.io/v1beta2 kind: RecurringJob metadata: name: recurring-snap-delete-per-min namespace: longhorn-system spec: concurrency: 1 cron: * * * * * groups: [] labels: {} name: recurring-snap-delete-per-min retain: 2 task: snapshot-delete任务完成后卷上无论快照来源将只剩 2 个最新快照。示例二snapshot-cleanup每分钟执行apiVersion: longhorn.io/v1beta2 kind: RecurringJob metadata: name: recurring-snap-cleanup-per-min namespace: longhorn-system spec: concurrency: 1 cron: * * * * * groups: [] labels: {} name: recurring-snap-cleanup-per-min task: snapshot-cleanup任务完成后卷上的系统快照数量应为 0。注意此例中无需也不应依赖retain字段——CRD 校验与控制器会在该任务类型下将其按 0 处理。字段说明依据当前仓库 CRD 定义以上字段的语义可在 chart/templates/crds.yaml 的RecurringJobSpec中逐项核对字段类型说明concurrencyinteger每次触发的快照/备份操作的并发度cronstringCron 调度表达式如* * * * *表示每分钟groupsarray定时任务所属分组供卷通过分组标签批量引用labelsobject应用到生成快照/备份的标签retaininteger保留的快照/备份数量仅count-based保留策略下生效taskstring任务类型合法枚举见 CRDsnapshot、snapshot-force-create、snapshot-cleanup、snapshot-delete、backup、backup-force-create、filesystem-trim、system-backup另外当前 CRD 还提供了retentionPolicy默认count-based可选age-based与retainAgeGo duration 字符串如10m、24h、8760h字段实现基于快照/备份年龄的过期清理。需要留意的是age-based保留策略与snapshot-delete/snapshot-cleanup任务互斥校验会直接拒绝task: snapshot-delete配合retentionPolicy: age-based的组合详见 enhancements/20260819-age-based-retention-for-recurring-jobs.md 的约束表。将任务绑定到卷RecurringJob本身是集群级定义需要通过标签机制挂到具体卷或 StorageClass 上源自 label-driven recurring job 设计卷标签引用单个任务recurring-job.longhorn.io/JobName: enabled卷标签引用任务分组recurring-job-group.longhorn.io/GroupName: enabled任务处于default分组时会对没有配置任何任务标签的卷自动生效StorageClass 侧通过persistence.recurringJobSelector配置enable: true时以jobList指定任务名或分组名例如[{name:backup, isGroup:true}]见 chart/README.md。绑定完成后调度器会为每个 RecurringJob 生成对应的 Kubernetes CronJob按cron表达式周期触发。底层执行流程从源码设计看实现设计文档明确了两个任务的执行路径都收敛到同一套清理函数差异只在输入的快照清单。snapshot-delete 执行链枚举过期快照列出卷上所有已过期快照逻辑与既有listSnapshotNamesForCleanup实现一致构造清理清单将上述快照名作为cleanupSnapshotNames传入清理入口doSnapshotCleanup执行 purge沿用既有的 purge 实现将标记删除的快照数据彻底清除释放存储空间。snapshot-cleanup 执行链仅调用doSnapshotCleanup执行 purge 步骤且清理对象限定为系统/可移除快照——因此无需快照枚举与保留数比较retain无任何作用。RecurringJob Mutate 规则控制器的 mutate变更逻辑会在任务类型为snapshot-cleanup时将spec.retain强制改写为 0以避免用户误以为设置了保留数会影响清理结果。从源码结构看listSnapshotNamesForCleanup与doSnapshotCleanup是清理管线的核心构件两类任务通过复用同一 purge 流程保证了清理行为的一致性与可测试性。相关全局设置与空间管理快照清理并非孤立功能实际部署时可配合以下 Longhorn 全局设置均可在 chart/README.md 及 chart/questions.yaml 中配置recurringJobMaxRetention单个 RecurringJob 允许保留的快照/备份最大数量上限snapshotMaxCount卷允许的最大快照数量2250默认 100超出会触发TooManySnapshots卷条件告警与snapshotCountWarningThreshold配合使用autoCleanupRecurringJobBackupSnapshot是否自动清理由定时备份任务生成的快照allowRecurringJobWhileVolumeDetached卷处于分离状态时是否自动挂载以执行定时任务snapshotHeavyTaskConcurrentLimit每节点并发执行的快照重任务如 purge、clone数量上限清理任务同样受此限流保护。一个典型的空间治理组合是snapshot-deleteretain2负责兜底回收所有来源快照 snapshot-cleanup按天调度负责清扫系统残留 全局snapshotMaxCount作为最后防线。测试计划如何验证清理行为设计文档给出了两条可复现的验证路径适用于本地测试集群验证 snapshot-delete创建卷创建 2 个卷备份创建 2 个手动快照创建task: snapshot-delete的 RecurringJob保留数自定将任务绑定到卷等待定时任务完成检查卷上快照数量应恰好等于 RecurringJob 的spec.retain。验证 snapshot-cleanup创建卷制造 2 个系统快照例如删除一个副本、执行一次在线扩容创建task: snapshot-cleanup的 RecurringJob将任务绑定到卷等待定时任务完成检查卷上系统快照数量应为 0同时手动快照不受影响。演进与注意事项发布节点该能力随 v1.5.0 一并发布升级前请确认目标版本 ≥ v1.5.0与卷组快照的交互后续的卷组快照设计enhancements/20260811-volume-group-snapshot.md明确说明snapshot-delete的 retain 计数作用于卷上的每一个快照因此它可能将组内成员快照老化清除并导致快照组进入 Degraded 状态——这是刻意保留的硬性保留上限行为防止被遗忘的组拖住快照导致snapshot-max-count触顶后新快照创建失败与 age-based 策略的互斥snapshot-delete/snapshot-cleanup不接受age-based保留策略配置前请检查 RecurringJob 的retentionPolicy字段。总结snapshot-delete与snapshot-cleanup补齐了 Longhorn 定时任务在快照回收维度上的能力拼图前者以保留数为准绳统一回收所有来源快照后者定向清扫系统快照残留。结合卷标签绑定、StorageClass 选择器与全局空间阈值设置你可以将快照生命周期管理完全自动化避免手动清理的运维负担与空间浪费。赞分享云原生存储高可用容器编排【免费下载链接】longhornCloud-Native distributed storage built on and for Kubernetes项目地址https://gitcode.com/gh_mirrors/lo/longhorn点击查看免费下载相关推荐Device Mapper 快照支持snapshot / snapshot-origin / snapshot-merge内核机制与 LVM2 实战指南Device Mapper 快照支持snapshot / snapshot origin / snapshot merge内核机制与 LVM2 实战指南 D操作系统内核驱动驱动开发虚拟化嵌入式网络存储Longhorn 扩展 CSI Snapshot 支持集群内 Longhorn 快照设计原理、配置实战与验证指南Longhorn 扩展 CSI Snapshot 支持集群内 Longhorn 快照设计原理、配置实战与验证指南 本指南以 Longhorn 增强设计文档 e云原生存储高可用容器编排AVA Snapshot Workflow 实战移除快照断言时数据的清理与保留机制AVA Snapshot Workflow 实战移除快照断言时数据的清理与保留机制 导读 在 AVA 测试框架中快照snapshot文件与测试代码的生命测试上一篇o_proxy_server路径重写实战正则捕获组URL重写技巧与10个实用示例下一篇【免费下载】 Nunchaku项目安装与配置指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考