Harvester集群升级中见证节点与存储副本的兼容性问题分析

问题背景

在Harvester v1.5版本中，当用户尝试升级一个包含见证节点的3节点集群时，系统会在"Pre-draining"阶段出现卡顿现象。这一现象特别发生在使用默认存储类(harvester-longhorn)且配置为3副本的情况下。而如果使用自定义存储类并设置副本数为2，则升级过程可以正常完成。

技术原理分析

Harvester的升级机制在"Pre-draining"阶段会检查所有运行中的Longhorn引擎状态，确保相关存储卷处于健康(healthy)状态后才能继续后续操作。在见证节点集群中，系统错误地将见证节点计入了节点总数，导致存储健康检查逻辑出现偏差。

具体表现为：

1. 系统通过kubectl查询所有标记为harvesterhci.io/managed=true的节点数量
2. 对于每个运行的Longhorn引擎，检查其对应存储卷的robustness状态
3. 当节点数大于2时，系统会等待存储卷达到healthy状态
4. 在见证节点集群中，见证节点被错误计入总数，而实际上它不参与存储副本维护

问题影响

这一缺陷会导致以下影响：

1. 升级过程停滞在Pre-draining阶段，无法自动继续
2. 存储卷状态显示为degraded(降级)而非healthy(健康)
3. 用户需要手动干预才能继续升级流程
4. 影响生产环境的维护窗口和升级计划

解决方案

Harvester团队通过修改节点计数逻辑修复了这一问题：

1. 在计算节点数量时排除了见证节点
2. 确保存储健康检查基于实际参与存储维护的节点数
3. 保持与Longhorn存储系统的副本数配置一致

最佳实践建议

对于使用见证节点配置的Harvester集群，建议：

1. 升级前检查存储类配置，确保副本数与实际节点匹配
2. 见证节点集群建议使用副本数为2的存储配置
3. 监控升级过程中的存储卷健康状态
4. 对于生产环境，先在测试环境验证升级流程

总结

这一问题的解决体现了Harvester对边缘计算场景下特殊配置的持续优化。通过精确识别节点角色和功能，系统能够更智能地处理存储健康检查和升级流程，为用户提供更稳定的升级体验。对于使用见证节点配置的用户，建议升级到包含此修复的v1.5.0-rc2或更高版本。