Longhorn存储引擎在节点滚动更新时陷入停止状态的技术分析

问题背景

在Kubernetes生产环境中使用Longhorn作为分布式存储解决方案时，运维团队在进行节点滚动更新操作时遇到了一个严重问题：部分存储引擎(Engine)和对应的副本(Replica)会陷入"stopped"状态，导致相关存储卷(Volume)无法成功挂载到Pod上。这种情况在Longhorn 1.7.x版本中尤为明显，影响了生产环境的稳定性。

问题现象

当集群执行节点滚动更新操作时，特别是通过Cluster API进行节点替换时，会出现以下典型症状：

1. 多个Engine组件进入"stopped"状态
2. 关联的存储卷无法完成挂载操作
3. Pod事件中反复出现"FailedAttachVolume"错误
4. 系统可能长时间(90分钟以上)无法自动恢复

根本原因分析

经过深入分析，这个问题主要由两个相互关联的因素导致：

1. 副本数量与调度条件的严格校验

在Longhorn 1.7.2版本中引入了一个关键变更：系统不仅检查现有副本是否已调度，还会严格比较当前副本数量与配置的副本数量(spec.numberOfReplicas)。当两者不匹配时，系统会将卷标记为"Scheduled=False"，进而导致卷处于"NotReadyForWorkload"状态。

这种设计在正常情况下可以防止数据不一致，但在节点滚动更新这种特殊场景下会产生问题：

• 当节点被排空(drain)和封锁(cordon)时，该节点上的副本会被标记为失败
• 系统会删除长时间处于失败状态的副本CR
• 由于卷处于分离(detached)状态，系统不会立即补充新副本
• 导致当前副本数量小于配置值，触发"Scheduled=False"状态
• 进而阻止卷重新挂载，形成死锁

2. 实例管理器(Instance Manager)不可用

另一个相关问题是当节点被封锁后：

• 节点上的实例管理器(Instance Manager)Pod无法启动
• 导致该节点上的副本无法正常运行
• 如果此时其他副本也出现问题，系统可能无法自动重建
• 特别是在"allow-volume-creation-with-degraded-availability=false"设置下，问题更加明显

解决方案与优化建议

针对这一问题，Longhorn团队已经制定了修复方案，并将包含在1.7.3和1.8.1版本中。主要改进包括：

1. 优化调度条件判断逻辑：调整卷"Scheduled"条件的判断逻辑，避免在节点滚动更新时产生死锁情况。

2. 临时解决方案：在生产环境可以暂时将"allow-volume-creation-with-degraded-availability"设置为true，虽然这不符合生产环境的最佳实践，但可以缓解问题。

3. 增强副本重建机制：改进副本重建逻辑，确保在节点维护期间也能保持足够的副本可用性。

最佳实践建议

对于使用Longhorn的生产环境，特别是在需要频繁进行节点维护的场景下，建议：

1. 在升级到1.7.3或1.8.1版本前，评估临时启用"allow-volume-creation-with-degraded-availability"的必要性

2. 进行节点滚动更新时，监控Longhorn卷的状态变化，特别是副本数量和调度状态

3. 考虑在维护窗口期进行节点更新，减少对业务的影响

4. 确保集群有足够的容量冗余，避免因单个节点不可用导致副本无法重建

总结

Longhorn存储引擎在节点滚动更新时陷入停止状态的问题，揭示了分布式存储系统在动态Kubernetes环境中的复杂性。通过深入分析问题根源，Longhorn团队已经找到了解决方案，并将通过后续版本更新提供给用户。对于生产环境用户，理解这一问题的影响范围和临时解决方案，可以帮助更好地规划系统维护和升级策略。