Harvester项目中的见证节点集群升级问题解析

问题背景

在Harvester虚拟化管理平台中，用户报告了一个关于见证节点(witness)集群升级的重要问题。当用户尝试升级一个由3个节点组成的见证集群(包含2个默认管理节点和1个见证节点)时，如果使用默认的存储类(副本数为3)，升级过程会在"Pre-draining"阶段卡住。而当用户使用自定义存储类(副本数为2)时，相同的升级操作则可以顺利完成。

技术分析

问题根源

经过深入分析，发现问题出在升级脚本的节点计数逻辑上。当前实现中，升级脚本通过查询所有带有harvesterhci.io/managed=true标签的节点来统计节点数量。然而在见证节点集群中，见证节点也应该被计入节点总数，但当前逻辑没有正确处理这种情况。

具体表现为：当使用默认存储类(副本数3)时，升级过程会等待upgrade-repo虚拟机的存储卷变为"healthy"状态。但由于见证节点的特殊性，存储卷状态会保持为"degraded"，导致升级流程无法继续。

解决方案

修复方案的核心是修改节点计数逻辑，确保在计算节点数量时正确排除见证节点。这需要调整升级脚本中的节点查询条件，使其能够识别并正确处理见证节点的特殊情况。

影响范围

此问题影响所有使用见证节点配置的Harvester集群，特别是当用户：

1. 使用默认存储类配置(副本数3)
2. 集群中包含见证节点
3. 尝试执行升级操作

修复验证

修复后，测试团队在以下环境中验证了解决方案的有效性：

• Harvester版本：v1.5.0-rc2
• 集群配置：3节点见证集群(2管理节点+1见证节点)
• 存储配置：默认harvester-longhorn存储类(副本数3)

测试结果表明，升级过程不再卡在"Pre-draining"阶段，能够顺利完成整个升级流程。

技术启示

这个问题揭示了分布式存储系统在特殊节点配置下的边缘情况处理重要性。在设计和实现集群管理功能时，需要考虑各种可能的节点角色组合及其对存储策略的影响。特别是在自动化的升级流程中，必须确保所有依赖组件状态的检查逻辑能够适应不同的集群拓扑结构。

对于使用Harvester的管理员来说，这个问题也提醒我们，在生产环境中使用特殊节点配置时，应该充分测试关键操作流程，或者考虑使用经过验证的存储类配置来避免潜在问题。