云原生存储高可用容器编排【免费下载链接】longhornCloud-Native distributed storage built on and for Kubernetes项目地址https://gitcode.com/gh_mirrors/lo/longhorn点击查看免费下载导读本文围绕 LonghornCloud-Native 分布式块存储构建于 Kubernetes 之上的卷删除流程展开重点讲解当用户删除一个**已附加Attached或关联了 Persistent VolumePV/ Persistent Volume ClaimPVC**的卷时系统如何通过 UI 警告、删除确认和控制器自动清理三层机制保障操作安全。读完本文你将掌握 Longhorn UI 删除卷时的两类警告场景、Volume Controller 对 PV/PVC 的级联清理逻辑、StorageClass 场景下的删除闭环以及对应的集成测试与手动验证方法。本文主体内容源自仓库中的增强设计文档 enhancements/20200625-volume-deletion-flows.md并结合作业仓库中的真实配置示例如 examples/csi/example_pv.yaml进行源码级佐证与实操扩充。背景删除一个卷可能带来的两类隐患在 Longhorn 中Volume是核心存储对象但它并不是孤立存在的。一个卷可能被 Kubernetes 的Persistent Volume甚至Persistent Volume Claim所引用也可能正处于被节点实例管理器附加Attach并供工作负载读写的工作状态。这两种状态在删除时都隐藏着风险遗留的 PV/PVC 指向不存在的卷如果在删除卷时不清理关联的 PV/PVC这些 Kubernetes 资源会继续存在但它们指向的底层卷已经消失。一旦有工作负载引用这些资源就会出现访问错误。删除正在使用的卷导致应用中断如果删除一个正处于 Attached 状态的卷正在使用该卷的应用将立即失去存储访问能力产生 I/O 错误甚至应用崩溃。本增强设计原始问题见 enhancements/20200625-volume-deletion-flows.md 中关联的 issue #520正是为了解决这两个问题在 Longhorn UI 中针对上述两类场景增加删除确认警告并让 longhorn-manager 在卷删除时自动清理关联的 Kubernetes 资源。目标与非目标Goals目标处理并警示删除卷可能引发问题的各种场景当删除卷时自动清理关联的Persistent Volume以及可能的Persistent Volume Claim避免在 Kubernetes 中遗留无法使用的卷相关资源。当删除处于 Attached 状态的卷时向用户提示删除可能对现有工作负载造成的后果让用户自行决定如何处置。Non-Goals非目标本增强并不打算完全阻止用户执行危险操作。例如如果用户坚持要删除一个当前已附加的卷系统不应禁止——因为用户可能非常确定自己要做这件事例如已提前完成数据迁移或备份。UI 警告的目的是告知而不是拦截。方案总览Proposal当用户从 Longhorn UI 发起删除卷操作时系统应检查该卷是否有关联资源或正处于 Attached 状态卷处于 Attached 状态在用户确认删除前警告删除的潜在后果——任何正在使用该卷的应用将失去访问能力并很可能报错。用户可以选择确认删除或取消。卷关联了 Persistent Volume可能还有 Persistent Volume Claim告知用户存在这些关联资源并说明删除卷后 longhorn-manager 会一并清理它们。如果卷还关联了 PVC则额外警告可能有Deployments或Stateful Sets依赖该卷删除后这些工作负载可能无法正常工作系统无法在不持续监控所有 Deployment/StatefulSet 的情况下精确判定哪些工作负载使用了 Longhorn 后端的 PVC。用户确认删除后系统将执行关联资源清理并完成卷的删除。用户故事从只弹默认确认框到知情删除场景一删除有关联资源的卷增强之前用户通过 longhorn-ui 删除卷时只会看到默认的确认提示。虽然用户可以从卷列表页面看到关联的 PV以及可能的 PVC但这些信息不会出现在确认对话框中而且删除卷后这些 PV/PVC 仍然存在一旦用户尝试在负载中使用它们就会因为底层卷已不存在而引发问题。增强之后删除确认对话框会明确告知用户存在关联资源并提示删除卷会触发这些资源的清理。用户仍可像往常一样自行决定是否继续删除。场景二删除已附加的卷增强之前删除一个 Attached 状态的卷时UI 只有默认确认信息不会提示卷正处于附加状态。用户可能在毫无警示的情况下删除卷导致使用该卷的应用出现错误。增强之后用户会被明确告知卷处于 Attached 状态从而能够根据实际情况决定删除操作以及如何处理正在使用该卷的应用。用户体验细节删除确认的完整交互流程删除有关联资源的卷用户尝试删除一个关联了Persistent Volume以及可能的Persistent Volume Claim的卷。确认对话框弹出要求用户确认操作并额外说明longhorn-manager 将删除与该卷关联的 Kubernetes 资源。如果卷还关联了 PVC用户会额外收到警告可能有Deployments或Stateful Sets正在使用该卷删除后可能产生不良影响。用户二选一点击Cancel取消不做任何操作返回卷列表页面。点击Confirm确认longhorn-manager 开始处理卷删除并自动清理关联的Persistent Volume和Persistent Volume Claim。删除已附加的卷用户从 longhorn-ui 删除一个当前处于 Attached 状态的卷。确认对话框弹出告知用户卷处于 Attached 状态删除可能导致使用该卷的应用报错。如果该卷同时被 Kubernetes 工作负载使用可通过卷的 Kubernetes Status 判定会一并提示这一信息。用户二选一点击Cancel不做任何操作返回卷列表页面。点击Confirmlonghorn-manager 处理卷删除。用户需自行负责处理因卷被删除而报错的应用。设计实现UI 警告与控制器清理的双层分工实现概览longhorn-ui 侧变更用户尝试删除卷时若卷关联了Persistent Volume可能还有Persistent Volume Claim在确认对话框中追加一条关于将清理这些关联资源的警告。若卷处于 Attached 状态在确认对话框中追加一条关于可能出现应用错误请自行评估后果的警告。longhorn-manager 侧变更在Volume Controller中如果卷带有Deletion Timestamp即已进入删除流程则检查卷的Kubernetes Status如果存在Persistent Volume删除之。如果存在Persistent Volume Claim删除之。也就是说删除操作本身对 API 调用方是透明的——API 层面删除卷的调用方式保持不变详见下文API 变化PV/PVC 的清理逻辑完全下沉到 Volume Controller 内部完成UI 与 API 客户端无需关心底层细节。源码佐证PV/PVC 与 Longhorn 卷的绑定关系要理解这套清理逻辑首先要看清 PV/PVC 与 Longhorn 卷之间的绑定方式。仓库中的 examples/csi/example_pv.yaml 给出了完整的示例apiVersion: v1 kind: PersistentVolume metadata: name: longhorn-vol-pv spec: capacity: storage: 2Gi volumeMode: Filesystem accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Delete storageClassName: longhorn csi: driver: driver.longhorn.io fsType: ext4 volumeAttributes: numberOfReplicas: 3 staleReplicaTimeout: 2880 volumeHandle: existing-longhorn-volume --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: longhorn-vol-pvc namespace: default spec: accessModes: - ReadWriteOnce resources: requests: storage: 2Gi volumeName: longhorn-vol-pv storageClassName: longhorn --- apiVersion: v1 kind: Pod metadata: name: volume-pv-test namespace: default spec: restartPolicy: Always containers: - name: volume-pv-test image: nginx:stable-alpine imagePullPolicy: IfNotPresent livenessProbe: exec: command: - ls - /data/lostfound initialDelaySeconds: 5 periodSeconds: 5 volumeMounts: - name: vol mountPath: /data ports: - containerPort: 80 volumes: - name: vol persistentVolumeClaim: claimName: longhorn-vol-pvc从这个示例中可以提炼出与卷删除清理直接相关的关键事实绑定关键点PV 通过spec.csi.volumeHandle本例为existing-longhorn-volume指向具体的 Longhorn 卷PVC 通过spec.volumeName指向 PVPod 通过volumes.persistentVolumeClaim.claimName绑定 PVC。这条卷 → PV → PVC → Pod的引用链正是 Volume Controller 通过卷的Kubernetes Status回溯并清理 PV/PVC 的依据。persistentVolumeReclaimPolicy: Delete回收策略为 Delete意味着 PV 被删除时底层存储Longhorn 卷也应被回收——这与设计文档 Notes 中关于 StorageClass 动态供给场景的删除闭环相互印证详见下文。driver 标识csi.driver: driver.longhorn.io表明这是 Longhorn CSI 驱动管理的卷只有这类卷才属于本清理逻辑的作用范围。API 变化删除调用不变清理逻辑收敛到控制器从 API 角度出发删除卷的调用方式看起来与之前完全一致——用户/UI 发出的删除请求没有任何新增参数。所有关于删除Persistent Volume或Persistent Volume Claim的逻辑都集中在Volume Controller中由控制器在卷带Deletion Timestamp后自主执行。这样的设计带来两个好处客户端零感知无论删除请求来自 longhorn-ui、longhornctl命令行还是直接调用 Longhorn API行为一致且无需改动。逻辑收敛清理策略只存在于一个地方Volume Controller便于维护与测试。测试计划集成测试与手动验证longhorn-manager 集成测试为验证本提案的控制器行为需要新增以下集成测试API 路径测试通过 API 创建一个卷然后为该卷创建Persistent Volume和Persistent Volume Claim等待卷的Kubernetes Status被填充尝试删除该卷。预期结果卷连同Persistent Volume、Persistent Volume Claim一并被删除。StorageClass 动态供给路径测试创建 Longhorn 的Storage Class用它为某个Persistent Volume Claim动态供给一个新的卷尝试删除该卷。预期结果卷连同Persistent Volume、Persistent Volume Claim一并被删除。longhorn-ui 手动测试从 longhorn-ui 创建一个新卷并为该卷创建Persistent Volume尝试删除该卷。预期结果确认对话框提示用户将删除相关 Kubernetes 资源。从 longhorn-ui 创建一个新卷并将其Attach尝试删除该卷。预期结果确认对话框提示卷正在使用中并警告可能出现的错误。通过 Kubernetes 创建一个卷并将其用于某个Pod从 longhorn-ui 尝试删除该卷。预期结果确认对话框中同时出现多条警告——一条提示将移除 Kubernetes 资源另一条警告卷正在使用中。上述测试覆盖了有关联资源已附加同时有关联资源且已附加三种组合场景与设计文档的用户故事一一对应。升级策略无需特殊的升级流程。用户将 Longhorn 升级到包含本增强的新版本后这些新能力会立即在 longhorn-ui 中生效无需额外配置或迁移操作。注意事项与边界场景关于保留 PV/PVC 的后续需求设计文档指出存在让用户自行决定是否保留 Persistent Volume以及可能的 Persistent Volume Claim的诉求——典型场景如从 Backup 恢复数据时。但这一诉求需要变更go-rancher生成 Go 客户端的方式使对资源的Delete请求能够携带输入参数因此在本提案中暂不实现属于后续演进方向。StorageClass 动态供给下的删除闭环对于通过Storage Class供给、且回收策略设置为PVC 删除后卷一并删除的场景无论删除由何种方式触发卷都应被正确删除从 UI 删除卷Volume Controller 删除Persistent Volume时会触发 CSI 服务器再发起一次卷删除调用这次调用会成功返回从而允许 PV 被删除、卷也被删除。因 PVC 删除而删除卷CSI 服务器会在删除Persistent Volume之前成功发起卷删除调用此时 Volume Controller 已没有额外资源需要清理可以顺利完成卷的最终删除。这一闭环保证了UI 删除与PVC 删除两条路径都不会留下孤儿资源或卡住的删除流程。总结Longhorn 的卷删除流程增强本质上是一套知情 自动清理的双层防护层组件职责用户告知层longhorn-ui在确认对话框中对关联 PV/PVC与Attached 状态两类场景追加警告把潜在风险前置告知用户资源清理层longhorn-managerVolume Controller检测卷的Deletion Timestamp读取Kubernetes Status级联删除关联的 PV/PVC该设计既保留了用户删除任意卷包括已附加卷的最终决定权非目标中明确不阻止危险操作又通过控制器自动清理避免了 Kubernetes 中遗留指向已删除卷的孤立资源。实现上删除 API 保持透明清理逻辑收敛于 Volume Controller 单一位置并以集成测试API 路径 StorageClass 路径与 UI 手动测试三种组合场景加以保障。对于需要删除卷但保留 PV/PVC的高级场景设计文档也已明确其依赖 go-rancher 客户端能力的演进方向可作为后续跟踪的线索。若需进一步深入可阅读仓库中的原始设计文档 enhancements/20200625-volume-deletion-flows.md、PV/PVC 绑定示例 examples/csi/example_pv.yaml以及 Longhorn 部署清单如 deploy/longhorn.yaml与 Helm Chart 配置chart/values.yaml。赞分享云原生存储高可用容器编排【免费下载链接】longhornCloud-Native distributed storage built on and for Kubernetes项目地址https://gitcode.com/gh_mirrors/lo/longhorn点击查看免费下载相关推荐Velero/Ark 删除备份命令详解ark delete backup 的用法、确认机制与底层删除流程Velero/Ark 删除备份命令详解 ark delete backup 的用法、确认机制与底层删除流程 本指南以 Velero 项目此前命名为 Ark云原生灾备存储后端如何安全高效清理容器存储container卷删除与VolumeDelete完整指南如何安全高效清理容器存储container卷删除与VolumeDelete完整指南 在使用container30创建和运行Linux容器时随着项目迭代和测试CLI虚拟化容器运行时云原生QuickRecorder 录屏完整指南一个 10MB 小工具搞定 macOS 系统声音与窗口录制QuickRecorder 录屏完整指南一个 10MB 小工具搞定 macOS 系统声音与窗口录制 QuickRecorder 是一款不到 10MB 的 ma桌面应用音视频屏幕录制创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
