Longhorn存储引擎在节点升级过程中"stopped"状态问题分析与解决方案

问题背景

在Kubernetes生产环境中，使用Longhorn作为分布式存储解决方案时，运维团队在进行集群节点滚动升级过程中发现了一个关键问题：部分存储引擎和副本会陷入"stopped"状态，导致相关存储卷无法正常挂载到Pod上。这个问题在Longhorn 1.7.2版本中尤为明显，特别是在启用了allowVolumeCreationWithDegradedAvailability: true配置的情况下。

问题现象

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

1. 多个存储卷长时间处于"attaching"状态
2. 相关Pod因无法挂载存储卷而启动失败
3. 检查副本状态时，发现部分副本处于"stopped"状态
4. 这些停止的副本通常位于被升级的节点上

根本原因分析

经过深入排查，发现问题主要由以下几个因素共同导致：

1. 磁盘UUID变更：在节点升级过程中，部分情况下底层存储磁盘会被重新格式化，导致磁盘UUID发生变化。Longhorn依赖磁盘UUID来识别和管理副本数据，UUID变更会导致引擎无法识别原有副本。

2. 副本状态不一致：升级后的节点上，原有的副本记录与新磁盘环境不匹配，系统无法自动恢复这些副本到正常运行状态。

3. 版本兼容性问题：在Longhorn 1.7.2版本中，对磁盘变更的处理机制不够完善，相比早期版本(1.5.x)更容易出现此问题。

解决方案

Longhorn团队在1.7.3版本中针对此问题进行了重要改进：

1. 增强的磁盘变更处理：改进了当检测到磁盘UUID变更时的处理逻辑，能够更智能地识别和处理这种情况。

2. 自动恢复机制优化：优化了副本状态不一致时的自动恢复流程，减少人工干预需求。

3. 配置建议：虽然allowVolumeCreationWithDegradedAvailability: true可以缓解问题，但最佳实践是在升级前确保磁盘配置一致性，并在1.7.3及以上版本中可安全地将其设回false。

最佳实践建议

基于此问题的分析，建议运维团队采取以下措施：

1. 版本升级：尽快升级到Longhorn 1.7.3或更高版本，以获得最稳定的节点升级体验。

2. 升级前检查：在执行节点滚动升级前，确认磁盘配置不会在升级过程中被修改。

3. 监控配置：确保监控系统能够及时发现并报告存储卷的异常状态。

4. 测试验证：在生产环境实施前，在测试环境中充分验证升级流程。

总结

Longhorn作为Kubernetes生态中重要的分布式存储解决方案，其稳定性和可靠性对生产环境至关重要。通过理解节点升级过程中可能遇到的存储引擎状态问题及其解决方案，运维团队可以更好地规划和管理集群维护工作。1.7.3版本的改进显著提升了在节点滚动升级场景下的稳定性，是生产环境推荐的版本选择。