Longhorn项目中的卷挂载失败问题分析与解决方案

问题现象

在Kubernetes环境中使用Longhorn作为存储解决方案时，用户报告了一个关于持久卷(PV)挂载失败的问题。具体表现为当尝试重新创建StatefulSet时，系统报错显示卷无法挂载到目标节点，原因是该卷当前仍被挂载在另一个不同的节点上。

错误信息明确指出："volume pvc-2efe11a5-8925-4da5-91db-99e5a79d82c8 failed to attach to node node3... the volume is currently attached to different node node1"。这种情况需要管理员手动执行分离(detach)和重新挂载(attach)操作才能恢复正常。

环境背景

问题出现在以下环境中：

• Longhorn版本：1.6.4
• Kubernetes发行版：EKS 1.29.5
• 节点配置：AlmaLinux 9.5操作系统，内核版本5.14.0-503.21.1.el9_5.x86_64
• 底层基础设施：VMWare虚拟化平台

问题根源分析

经过技术团队深入调查，发现问题根源在于Longhorn UI手动操作遗留的"attachment ticket"。这些ticket会阻止CSI(容器存储接口)的正常挂载操作。具体表现为：

1. 系统中存在多个标记为"longhorn-ui"的attachment ticket
2. 这些ticket状态显示为"Satisfied: true"
3. 当工作负载尝试使用该卷时，这些手动创建的ticket会与CSI自动创建的ticket产生冲突

解决方案

要解决此问题，可以按照以下步骤操作：

1. 首先列出所有的volumeattachment资源：

kubectl -n longhorn-system get volumeattachments.longhorn.io -oyaml

2. 对于包含"longhorn-ui" ticket的资源，编辑对应的volumeattachment对象：

kubectl -n longhorn-system edit volumeattachments.longhorn.io <volume name>

3. 在编辑器中，找到spec部分下的longhorn-ui ticket并将其移除

4. 保存更改后，系统应该能够正常完成卷的自动挂载操作

最佳实践建议

为避免此类问题再次发生，建议：

1. 尽量避免通过Longhorn UI手动挂载/卸载卷，特别是生产环境中
2. 如果需要手动操作，完成后记得清理相关的attachment ticket
3. 定期检查系统中是否存在异常的attachment ticket
4. 考虑在CI/CD流程中加入对volumeattachment状态的检查

技术原理深入

Longhorn的卷挂载机制依赖于Kubernetes的VolumeAttachment资源和Longhorn自定义的attachment ticket系统。当多个ticket同时存在时，系统可能会出现冲突。CSI驱动在尝试挂载卷时，会检查卷的当前状态，如果发现卷已被其他节点占用，就会拒绝挂载请求以保持数据一致性。

理解这一机制有助于管理员更好地诊断和解决类似存储问题，同时也能在设计应用架构时做出更合理的存储决策。