尧图网站建设 
云原生存储高可用容器编排【免费下载链接】longhornCloud-Native distributed storage built on and for Kubernetes项目地址https://gitcode.com/gh_mirrors/lo/longhorn点击查看免费下载导读在 Longhorn 这类云原生分布式存储系统中节点或磁盘在异常下线、重建、迁移后磁盘上常会残留不再被系统跟踪的副本数据目录orphaned replica directories持续占用磁盘容量且难以清理。本文基于 Longhorn 的orphaned-data-cleanup设计文档完整讲解其孤儿副本目录识别 → Orphan CR 跟踪 → 手动/自动删除的实现机制包括新引入的orphanCRD 与控制器、节点级 monitor 的扫描与判定逻辑、orphan-auto-deletion全局自动清理设置以及 GUI 与kubectl两种运维操作方式并补充当前仓库v1.12.0-dev中该特性演进后的 CRD 定义与设置项全貌帮助你彻底掌握 Longhorn 孤儿数据的治理能力。背景孤儿副本目录从何而来Longhorn 将每个卷副本replica的数据存放在节点磁盘的${disk_path}/replicas/replica-name-random-string目录中。正常情况下这些目录与 Longhorn 的 Replica CR 一一对应由系统统一管理。但在以下两种典型场景中磁盘上会出现不再被 Longhorn 系统跟踪的副本数据目录即孤儿用户将一块磁盘引入 Longhorn 节点时磁盘上可能已经带有来自其他 Longhorn 集群的副本目录这些目录从未被当前系统登记节点或磁盘下线期间与这些副本目录关联的 Replica CR 被系统移除当节点/磁盘重新上线时对应的副本数据目录已没有任何 CR 引用成为无主数据。这些孤儿副本目录会持续占用 Longhorn 磁盘容量。在引入自动清理机制之前用户只能人工逐一对比节点磁盘上的目录与系统跟踪的副本清单再手动删除过程繁琐且耗时。目标与非目标设计目标识别节点磁盘上的孤儿副本目录扫描过程不得阻塞节点控制器的 reconcile 循环为用户提供选择并触发删除孤儿副本目录的途径支持全局自动删除孤儿副本目录。明确的非目标不清理磁盘路径下未知的文件或目录只针对副本目录不支持按节点粒度的孤儿自动删除自动删除仅全局生效不支持对超过 TTL 的孤儿副本目录自动删除。整体方案一个 CRD 两处控制器该设计围绕三个核心组件展开orphanCRD新增的定制资源用于表示与跟踪每个孤儿副本目录是用户在 GUI /kubectl中操作的对象节点级 monitor在每个节点的控制器内启动周期性扫描磁盘上的副本目录并识别孤儿Orphan 控制器负责在收到删除请求时删除磁盘上的物理数据目录与对应的orphan资源。节点控制器与 monitor 的协同流程节点控制器Node Controller的 reconcile 循环与 per-node monitor 通过syncWithMonitor协作整体流程如下图所示queue ┌───────────────┐ ┌──────────────────────┐ ┌┐ ┌┐ ┌┐ │ │ │ │ ... ││ ││ ││ ──────► │ syncNode() ├────────────►│ reconcile() │ └┘ └┘ └┘ │ │ │ │ └───────────────┘ └───────────┬──────────┘ │ syncWithMonitor │ │ ┌───────────▼──────────┐ │ │ │ per-node monitor │ │ | ┤ collect information │ │ │ └──────────────────────┘Node controller在初始化时启动 monitor并在每次 reconcile 循环中与 monitor 同步执行以下职责从 monitor 获取最新磁盘状态与孤儿副本目录列表更新 node/disk 状态基于 monitor 收集的信息创建orphanCR当 node/disk 被请求驱逐evicted时删除关联的orphanCR注意此时不会清理磁盘上的物理数据目录当对应目录消失时删除orphanCR当全局自动删除设置开启时主动发出孤儿删除请求。Node monitor的核心数据结构如下type NodeMonitor struct { logger logrus.FieldLogger ds *datastore.DataStore node longhorn.Node lock sync.RWMutex onDiskReplicaDirectories map[string][string]string syncCallback func(key string) ctx context.Context quit context.CancelFunc }其中onDiskReplicaDirectories保存上一次扫描到的磁盘副本目录记录用于与最新扫描结果比对、判断目录集合是否发生变化。monitor 周期性执行两类检测1. 磁盘可用性检测运行stat检查磁盘挂载状态、检查磁盘 FSID、校验磁盘 metafile 中的磁盘 UUID确保只有健康的磁盘才会进入副本扫描流程。2. 孤儿目录识别列出${disk_path}/replicas下所有目录与monitor.onDiskReplicaDirectories中保存的上次记录比较若两份列表不一致则遍历${disk_path}/replicas下的全部目录识别出其中的孤儿副本目录将孤儿目录列表与node.status.diskStatus.scheduledReplica系统已调度的副本比对剔除仍被跟踪的目录最终得到孤儿副本目录清单存入monitor.node.status.diskStatus.orphanedReplicaDirectoryNames。什么是一个有效副本目录monitor 判定孤儿副本目录的依据是一个被 Longhorn 跟踪的有效副本目录必须具备以下两个属性缺少任一属性即视为孤儿目录命名格式必须为disk path/replicas/replica name-random string目录内的volume.meta文件必须可解析且符合volume.meta的格式规范。只要目录不满足上述任一条件或不在scheduledReplica清单中就会被识别为孤儿副本目录。orphanCRD 详解设计文档中的 Spec/Status 结构设计阶段定义的 Orphan 资源结构如下// OrphanSpec defines the desired state of the Longhorn orphaned data type OrphanSpec struct { // The node ID on which the controller is responsible to reconcile this orphan CR. // optional NodeID string json:nodeID // The type of the orphaned data. // Can be replica. // optional Type OrphanType json:type // The parameters of the orphaned data // optional // nullable Parameters map[string]string json:parameters } // OrphanStatus defines the observed state of the Longhorn orphaned data type OrphanStatus struct { // optional OwnerID string json:ownerID // optional // nullable Conditions []Condition json:conditions }当前仓库中的实际 CRD 定义该设计落地后已固化在 Longhorn 的部署清单中。查看 chart/templates/crds.yaml等价定义同时存在于 deploy/longhorn.yaml 与 deploy/longhorn-okd.yaml实际 CRD 为orphans.longhorn.iogrouplonghorn.ioscopeNamespaced命名空间级资源kindOrphanlistKindOrphanListshortNamelho便于 kubectl 简写使用版本当前为v1beta2提供额外的 printer columns——Type映射到spec.orphanType与Node映射到spec.nodeID便于kubectl get orphans直接展示关键信息spec字段nodeID负责 reconcile 该 orphan CR 的节点 IDorphanType孤儿数据类型设计文档中为replica当前定义扩展为枚举v1/v2dataEngine字段用于标识 v1 / v2 数据引擎parameters孤儿数据的参数map[string]string类型status字段ownerID与conditions复用 Longhorn 标准的 Condition 结构含lastProbeTime、lastTransitionTime、message、reason、status、type等字段。在 RBAC 侧chart/templates/clusterrole.yaml 与 deploy/longhorn.yaml 中均授权了对orphans与orphans/status资源的读写权限供 longhorn-manager 与 UI 后端使用。Orphan 控制器的职责若收到孤儿删除请求同时删除磁盘上的孤儿副本目录和对应的orphan资源若全局自动删除设置开启则由节点控制器统一发起孤儿删除请求。全局自动清理设置及其演进设计阶段orphan-auto-deletion设计文档定义了一个名为orphan-auto-deletion的全局设置默认值为false关闭。开启后节点控制器会在发现孤儿副本目录时直接发起删除实现自动清理。当前仓库中的设置形态v1.9.0 起在 Longhorn v1.9.0 中orphan-auto-deletion已被orphan-resource-auto-deletion取代见 CHANGELOG/CHANGELOG-1.9.0.md。该设置从布尔值演进为以分号分隔的资源类型列表例如replica-data;instance合法取值包括replica-data自动删除孤儿副本数据目录instance自动删除孤儿实例如不再关联活跃卷的 replica / engine 残留进程。升级过程中旧的orphan-auto-deletion值会自动迁移若要复现旧行为需在orphan-resource-auto-deletion中包含replica-data。当前 Helm Chart 中对应的配置项如下见 chart/values.yaml# -- Enables Longhorn to automatically delete orphaned resources and their associated data or processes (e.g., stale replicas). # Orphaned resources on failed or unknown nodes are not automatically cleaned up. # You need to specify the resource types to be deleted using a semicolon-separated list (e.g., replica-data;instance). # Available items are: replica-data, instance. orphanResourceAutoDeletion: ~ # -- Specifies the wait time, in seconds, before Longhorn automatically deletes an orphaned Custom Resource (CR) and its associated resources. # Note that if a user manually deletes an orphaned CR, the deletion occurs immediately and does not respect this grace period. orphanResourceAutoDeletionGracePeriod: ~配套的还有orphan-resource-auto-deletion-grace-period默认 300 秒自动删除前等待的宽限期若用户手动删除孤儿 CR则立即删除、不经过宽限期。两个设置项在 chart/templates/default-setting.yaml 中写入default-settingConfigMap并已在 chart/README.md 与 chart/questions.yaml 中登记文档说明与表单配置。需要注意的是位于失败或未知节点上的孤儿资源不会被自动清理——这是自动删除机制刻意保留的安全边界避免误删可能仍有用处的数据。用户操作指南通过 Longhorn GUI查看Node与Disk状态页即可看到 Longhorn 是否已识别出孤儿副本节点页面上会展示孤儿列表在孤儿副本目录列表中勾选需要清理的条目执行清理操作前端通过OrphanList拉取列表、通过OrphanDelete发起删除在设置页面开启全局自动删除选项默认关闭。通过kubectl列出所有孤儿副本目录kubectl -n longhorn-system get orphans由于 CRD 定义了 shortNamelho也可以使用kubectl -n longhorn-system get lho简写查看。输出中会直接呈现每个孤儿的Type与所在Node两列便于快速定位。删除指定孤儿副本目录会同时删除磁盘上的物理数据与 orphan 资源kubectl -n longhorn-system delete orphan name开启全局自动删除当前版本为orphan-resource-auto-deletionkubectl -n longhorn-system edit settings orphan-resource-auto-deletion按需写入replica-data自动删除孤儿副本数据或replica-data;instance同时清理孤儿实例。自动删除的行为细节与边界全局自动删除开启后由节点控制器统一对孤儿发起删除请求Orphan 控制器负责实际删除磁盘目录与 CR节点/磁盘驱逐或下线场景此时orphanCR 会被移除但磁盘上的孤儿副本目录不会被清理——因为节点不可达时无法安全执行删除数据得以保留目录自然消失场景若孤儿目录因外部原因自行消失关联的orphanCR 会被自动删除避免残留过期资源自动删除存在 300 秒默认宽限期orphan-resource-auto-deletion-grace-period手动删除则立即生效失败或未知节点上的孤儿资源不做自动清理。测试计划与验证要点设计文档配套的集成测试覆盖了以下核心场景磁盘路径下存在孤儿副本目录时orphanCR 被正确创建并可随目录一同被清理磁盘路径下存在多种文件/目录混合时orphanCR 仍能被正确创建并清理孤儿副本目录消失后对应orphanCR 被移除节点/磁盘被驱逐或下线时orphanCR 被移除但关联的孤儿副本目录不被清理全局自动删除设置开启后的端到端自动清理行为。特性演进小结从设计文档到当前仓库孤儿数据清理能力经历了清晰的演进维度设计阶段v1.x 早期当前仓库v1.9.0 / v1.12.0-devCRDorphantype:replicaorphans.longhorn.iov1beta2shortNamelho支持dataEnginev1/v2自动删除设置orphan-auto-deletion布尔默认 falseorphan-resource-auto-deletionreplica-data;instance列表自动删除宽限期不支持orphan-resource-auto-deletion-grace-period默认 300s治理范围仅副本目录副本目录 孤儿实例v1.9.0 新增 orphaned instance 清理该特性源于 Longhorn 的 issue #685Orphaned Replica Directory Cleanup其设计文档 enhancements/20220324-orphaned-data-cleanup.md 完整记录了这一机制的架构与决策。后续的 enhancements/20250331-orphaned-runtime-cleanup.md 进一步扩展了孤儿运行时资源的治理对应 v1.9.0 的 orphaned instance 清理能力。实际运维中建议遵循先扫描识别 → 人工核对 → 再决定自动删除的节奏默认保持自动删除关闭借助kubectl get orphans与 GUI 节点页先摸清集群中孤儿数据分布确认无保留价值后再开启orphan-resource-auto-deletion让 Longhorn 自动回收被孤儿副本占用的磁盘容量。赞分享云原生存储高可用容器编排【免费下载链接】longhornCloud-Native distributed storage built on and for Kubernetes项目地址https://gitcode.com/gh_mirrors/lo/longhorn点击查看免费下载相关推荐Rolldown Lazy Compilation 深入解析实现原理、数据生命周期与工程实践Rolldown Lazy Compilation 深入解析实现原理、数据生命周期与工程实践 导读 Lazy Compilation懒编译是 Rolldo云原生存储高可用容器编排Docker Compose CLI kill 命令详解强制停止服务容器、信号控制与孤儿容器清理Docker Compose CLI kill 命令详解强制停止服务容器、信号控制与孤儿容器清理 docker compose kill 用于向 Compos云原生容器编排DevOpsCLI上一篇10个sebastian/object-enumerator实用场景从单元测试到对象分析下一篇LightGBM生产实践大规模数据与实时推理创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Longhorn 孤儿副本数据清理（Orphaned Data Cleanup）机制详解
云原生存储高可用容器编排【免费下载链接】longhornCloud-Native distributed storage built on and for Kubernetes项目地址https://gitcode.com/gh_mirrors/lo/longhorn点击查看免费下载导读在 Longhorn 这类云原生分布式存储系统中节点或磁盘在异常下线、重建、迁移后磁盘上常会残留不再被系统跟踪的副本数据目录orphaned replica directories持续占用磁盘容量且难以清理。本文基于 Longhorn 的orphaned-data-cleanup设计文档完整讲解其孤儿副本目录识别 → Orphan CR 跟踪 → 手动/自动删除的实现机制包括新引入的orphanCRD 与控制器、节点级 monitor 的扫描与判定逻辑、orphan-auto-deletion全局自动清理设置以及 GUI 与kubectl两种运维操作方式并补充当前仓库v1.12.0-dev中该特性演进后的 CRD 定义与设置项全貌帮助你彻底掌握 Longhorn 孤儿数据的治理能力。背景孤儿副本目录从何而来Longhorn 将每个卷副本replica的数据存放在节点磁盘的${disk_path}/replicas/replica-name-random-string目录中。正常情况下这些目录与 Longhorn 的 Replica CR 一一对应由系统统一管理。但在以下两种典型场景中磁盘上会出现不再被 Longhorn 系统跟踪的副本数据目录即孤儿用户将一块磁盘引入 Longhorn 节点时磁盘上可能已经带有来自其他 Longhorn 集群的副本目录这些目录从未被当前系统登记节点或磁盘下线期间与这些副本目录关联的 Replica CR 被系统移除当节点/磁盘重新上线时对应的副本数据目录已没有任何 CR 引用成为无主数据。这些孤儿副本目录会持续占用 Longhorn 磁盘容量。在引入自动清理机制之前用户只能人工逐一对比节点磁盘上的目录与系统跟踪的副本清单再手动删除过程繁琐且耗时。目标与非目标设计目标识别节点磁盘上的孤儿副本目录扫描过程不得阻塞节点控制器的 reconcile 循环为用户提供选择并触发删除孤儿副本目录的途径支持全局自动删除孤儿副本目录。明确的非目标不清理磁盘路径下未知的文件或目录只针对副本目录不支持按节点粒度的孤儿自动删除自动删除仅全局生效不支持对超过 TTL 的孤儿副本目录自动删除。整体方案一个 CRD 两处控制器该设计围绕三个核心组件展开orphanCRD新增的定制资源用于表示与跟踪每个孤儿副本目录是用户在 GUI /kubectl中操作的对象节点级 monitor在每个节点的控制器内启动周期性扫描磁盘上的副本目录并识别孤儿Orphan 控制器负责在收到删除请求时删除磁盘上的物理数据目录与对应的orphan资源。节点控制器与 monitor 的协同流程节点控制器Node Controller的 reconcile 循环与 per-node monitor 通过syncWithMonitor协作整体流程如下图所示queue ┌───────────────┐ ┌──────────────────────┐ ┌┐ ┌┐ ┌┐ │ │ │ │ ... ││ ││ ││ ──────► │ syncNode() ├────────────►│ reconcile() │ └┘ └┘ └┘ │ │ │ │ └───────────────┘ └───────────┬──────────┘ │ syncWithMonitor │ │ ┌───────────▼──────────┐ │ │ │ per-node monitor │ │ | ┤ collect information │ │ │ └──────────────────────┘Node controller在初始化时启动 monitor并在每次 reconcile 循环中与 monitor 同步执行以下职责从 monitor 获取最新磁盘状态与孤儿副本目录列表更新 node/disk 状态基于 monitor 收集的信息创建orphanCR当 node/disk 被请求驱逐evicted时删除关联的orphanCR注意此时不会清理磁盘上的物理数据目录当对应目录消失时删除orphanCR当全局自动删除设置开启时主动发出孤儿删除请求。Node monitor的核心数据结构如下type NodeMonitor struct { logger logrus.FieldLogger ds *datastore.DataStore node longhorn.Node lock sync.RWMutex onDiskReplicaDirectories map[string][string]string syncCallback func(key string) ctx context.Context quit context.CancelFunc }其中onDiskReplicaDirectories保存上一次扫描到的磁盘副本目录记录用于与最新扫描结果比对、判断目录集合是否发生变化。monitor 周期性执行两类检测1. 磁盘可用性检测运行stat检查磁盘挂载状态、检查磁盘 FSID、校验磁盘 metafile 中的磁盘 UUID确保只有健康的磁盘才会进入副本扫描流程。2. 孤儿目录识别列出${disk_path}/replicas下所有目录与monitor.onDiskReplicaDirectories中保存的上次记录比较若两份列表不一致则遍历${disk_path}/replicas下的全部目录识别出其中的孤儿副本目录将孤儿目录列表与node.status.diskStatus.scheduledReplica系统已调度的副本比对剔除仍被跟踪的目录最终得到孤儿副本目录清单存入monitor.node.status.diskStatus.orphanedReplicaDirectoryNames。什么是一个有效副本目录monitor 判定孤儿副本目录的依据是一个被 Longhorn 跟踪的有效副本目录必须具备以下两个属性缺少任一属性即视为孤儿目录命名格式必须为disk path/replicas/replica name-random string目录内的volume.meta文件必须可解析且符合volume.meta的格式规范。只要目录不满足上述任一条件或不在scheduledReplica清单中就会被识别为孤儿副本目录。orphanCRD 详解设计文档中的 Spec/Status 结构设计阶段定义的 Orphan 资源结构如下// OrphanSpec defines the desired state of the Longhorn orphaned data type OrphanSpec struct { // The node ID on which the controller is responsible to reconcile this orphan CR. // optional NodeID string json:nodeID // The type of the orphaned data. // Can be replica. // optional Type OrphanType json:type // The parameters of the orphaned data // optional // nullable Parameters map[string]string json:parameters } // OrphanStatus defines the observed state of the Longhorn orphaned data type OrphanStatus struct { // optional OwnerID string json:ownerID // optional // nullable Conditions []Condition json:conditions }当前仓库中的实际 CRD 定义该设计落地后已固化在 Longhorn 的部署清单中。查看 chart/templates/crds.yaml等价定义同时存在于 deploy/longhorn.yaml 与 deploy/longhorn-okd.yaml实际 CRD 为orphans.longhorn.iogrouplonghorn.ioscopeNamespaced命名空间级资源kindOrphanlistKindOrphanListshortNamelho便于 kubectl 简写使用版本当前为v1beta2提供额外的 printer columns——Type映射到spec.orphanType与Node映射到spec.nodeID便于kubectl get orphans直接展示关键信息spec字段nodeID负责 reconcile 该 orphan CR 的节点 IDorphanType孤儿数据类型设计文档中为replica当前定义扩展为枚举v1/v2dataEngine字段用于标识 v1 / v2 数据引擎parameters孤儿数据的参数map[string]string类型status字段ownerID与conditions复用 Longhorn 标准的 Condition 结构含lastProbeTime、lastTransitionTime、message、reason、status、type等字段。在 RBAC 侧chart/templates/clusterrole.yaml 与 deploy/longhorn.yaml 中均授权了对orphans与orphans/status资源的读写权限供 longhorn-manager 与 UI 后端使用。Orphan 控制器的职责若收到孤儿删除请求同时删除磁盘上的孤儿副本目录和对应的orphan资源若全局自动删除设置开启则由节点控制器统一发起孤儿删除请求。全局自动清理设置及其演进设计阶段orphan-auto-deletion设计文档定义了一个名为orphan-auto-deletion的全局设置默认值为false关闭。开启后节点控制器会在发现孤儿副本目录时直接发起删除实现自动清理。当前仓库中的设置形态v1.9.0 起在 Longhorn v1.9.0 中orphan-auto-deletion已被orphan-resource-auto-deletion取代见 CHANGELOG/CHANGELOG-1.9.0.md。该设置从布尔值演进为以分号分隔的资源类型列表例如replica-data;instance合法取值包括replica-data自动删除孤儿副本数据目录instance自动删除孤儿实例如不再关联活跃卷的 replica / engine 残留进程。升级过程中旧的orphan-auto-deletion值会自动迁移若要复现旧行为需在orphan-resource-auto-deletion中包含replica-data。当前 Helm Chart 中对应的配置项如下见 chart/values.yaml# -- Enables Longhorn to automatically delete orphaned resources and their associated data or processes (e.g., stale replicas). # Orphaned resources on failed or unknown nodes are not automatically cleaned up. # You need to specify the resource types to be deleted using a semicolon-separated list (e.g., replica-data;instance). # Available items are: replica-data, instance. orphanResourceAutoDeletion: ~ # -- Specifies the wait time, in seconds, before Longhorn automatically deletes an orphaned Custom Resource (CR) and its associated resources. # Note that if a user manually deletes an orphaned CR, the deletion occurs immediately and does not respect this grace period. orphanResourceAutoDeletionGracePeriod: ~配套的还有orphan-resource-auto-deletion-grace-period默认 300 秒自动删除前等待的宽限期若用户手动删除孤儿 CR则立即删除、不经过宽限期。两个设置项在 chart/templates/default-setting.yaml 中写入default-settingConfigMap并已在 chart/README.md 与 chart/questions.yaml 中登记文档说明与表单配置。需要注意的是位于失败或未知节点上的孤儿资源不会被自动清理——这是自动删除机制刻意保留的安全边界避免误删可能仍有用处的数据。用户操作指南通过 Longhorn GUI查看Node与Disk状态页即可看到 Longhorn 是否已识别出孤儿副本节点页面上会展示孤儿列表在孤儿副本目录列表中勾选需要清理的条目执行清理操作前端通过OrphanList拉取列表、通过OrphanDelete发起删除在设置页面开启全局自动删除选项默认关闭。通过kubectl列出所有孤儿副本目录kubectl -n longhorn-system get orphans由于 CRD 定义了 shortNamelho也可以使用kubectl -n longhorn-system get lho简写查看。输出中会直接呈现每个孤儿的Type与所在Node两列便于快速定位。删除指定孤儿副本目录会同时删除磁盘上的物理数据与 orphan 资源kubectl -n longhorn-system delete orphan name开启全局自动删除当前版本为orphan-resource-auto-deletionkubectl -n longhorn-system edit settings orphan-resource-auto-deletion按需写入replica-data自动删除孤儿副本数据或replica-data;instance同时清理孤儿实例。自动删除的行为细节与边界全局自动删除开启后由节点控制器统一对孤儿发起删除请求Orphan 控制器负责实际删除磁盘目录与 CR节点/磁盘驱逐或下线场景此时orphanCR 会被移除但磁盘上的孤儿副本目录不会被清理——因为节点不可达时无法安全执行删除数据得以保留目录自然消失场景若孤儿目录因外部原因自行消失关联的orphanCR 会被自动删除避免残留过期资源自动删除存在 300 秒默认宽限期orphan-resource-auto-deletion-grace-period手动删除则立即生效失败或未知节点上的孤儿资源不做自动清理。测试计划与验证要点设计文档配套的集成测试覆盖了以下核心场景磁盘路径下存在孤儿副本目录时orphanCR 被正确创建并可随目录一同被清理磁盘路径下存在多种文件/目录混合时orphanCR 仍能被正确创建并清理孤儿副本目录消失后对应orphanCR 被移除节点/磁盘被驱逐或下线时orphanCR 被移除但关联的孤儿副本目录不被清理全局自动删除设置开启后的端到端自动清理行为。特性演进小结从设计文档到当前仓库孤儿数据清理能力经历了清晰的演进维度设计阶段v1.x 早期当前仓库v1.9.0 / v1.12.0-devCRDorphantype:replicaorphans.longhorn.iov1beta2shortNamelho支持dataEnginev1/v2自动删除设置orphan-auto-deletion布尔默认 falseorphan-resource-auto-deletionreplica-data;instance列表自动删除宽限期不支持orphan-resource-auto-deletion-grace-period默认 300s治理范围仅副本目录副本目录 孤儿实例v1.9.0 新增 orphaned instance 清理该特性源于 Longhorn 的 issue #685Orphaned Replica Directory Cleanup其设计文档 enhancements/20220324-orphaned-data-cleanup.md 完整记录了这一机制的架构与决策。后续的 enhancements/20250331-orphaned-runtime-cleanup.md 进一步扩展了孤儿运行时资源的治理对应 v1.9.0 的 orphaned instance 清理能力。实际运维中建议遵循先扫描识别 → 人工核对 → 再决定自动删除的节奏默认保持自动删除关闭借助kubectl get orphans与 GUI 节点页先摸清集群中孤儿数据分布确认无保留价值后再开启orphan-resource-auto-deletion让 Longhorn 自动回收被孤儿副本占用的磁盘容量。赞分享云原生存储高可用容器编排【免费下载链接】longhornCloud-Native distributed storage built on and for Kubernetes项目地址https://gitcode.com/gh_mirrors/lo/longhorn点击查看免费下载相关推荐Rolldown Lazy Compilation 深入解析实现原理、数据生命周期与工程实践Rolldown Lazy Compilation 深入解析实现原理、数据生命周期与工程实践 导读 Lazy Compilation懒编译是 Rolldo云原生存储高可用容器编排Docker Compose CLI kill 命令详解强制停止服务容器、信号控制与孤儿容器清理Docker Compose CLI kill 命令详解强制停止服务容器、信号控制与孤儿容器清理 docker compose kill 用于向 Compos云原生容器编排DevOpsCLI上一篇10个sebastian/object-enumerator实用场景从单元测试到对象分析下一篇LightGBM生产实践大规模数据与实时推理创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考