Harvester 1.5.0 升级实战经验与问题分析

升级背景

Harvester作为基于Kubernetes构建的开源超融合基础设施(HCI)解决方案，其1.5.0版本的升级过程相比之前版本有了显著改进。本文记录了从1.4.2版本升级到1.5.0版本的实际操作经验，重点分析遇到的问题及解决方案，为后续用户提供参考。

环境概况

本次升级环境包含3台裸金属服务器组成的集群，运行约60个虚拟机。基础架构采用Rancher 2.11.1管理，存储后端使用Longhorn。

升级准备

在升级前，我们手动禁用了自动升级检查功能，并预先添加了v1.5.0版本信息以便提前进行升级。这一步骤对于需要在正式发布前进行升级的用户尤为重要。

升级过程中遇到的问题

1. PCI直通设备的虚拟机处理

现象：使用PCI直通或特定节点调度的虚拟机需要完全关闭，无法随节点重启自动恢复。

分析：当前升级逻辑要求这类特殊配置的虚拟机必须完全关闭，而不是在节点处理时优雅关闭并在重启后自动恢复。这与常规虚拟机的处理方式不同，增加了操作复杂度。

建议：升级控制器应改进对特殊配置虚拟机的处理逻辑，允许它们在节点升级期间优雅关闭并在节点恢复后自动重启。

2. 虚拟机随机断电问题

现象：升级开始几分钟后，约三分之二的虚拟机被非正常断电，而非优雅关闭。

深入分析：日志检查发现某些节点未执行预排空(pre-drain)脚本就直接进行了RKE2二进制升级，导致kubelet重启时强制终止了所有虚拟机。可能的原因是节点之前进入过维护模式，某些标签状态异常导致升级流程判断失误。

解决方案：在升级前确保所有节点状态正常，必要时手动检查并清理残留标签。对于已发生的问题，可以手动重启受影响的虚拟机。

3. Prometheus内存不足

现象：升级期间Prometheus Pod因OOM被频繁杀死。

技术背景：升级过程中系统活动激增，导致监控数据量大幅增加，超出Prometheus默认资源配置。

解决方法：调整Prometheus Helm chart配置，增加内存预留和限制，确保其能够处理升级期间的高负载。

4. Longhorn实例管理器阻塞

现象：部分节点升级因Longhorn实例管理器(instance-manager)锁定而停滞。

底层机制：这与Longhorn的分布式锁机制有关，当实例管理器出现异常时，会阻止卷操作，进而影响节点升级。

处理方案：手动终止有问题的实例管理器，等待所有卷状态恢复健康后再继续升级。需要密切监控Longhorn卷状态，确保数据安全。

升级结果评估

尽管遇到上述问题，本次升级整体上比以往版本更为顺利。关键改进包括：

1. 迁移过程成功率显著提高
2. 总停机时间大幅缩短（约4小时完成）
3. 系统最终状态更加稳定

相比之下，早期版本的升级往往需要24小时以上才能完全恢复。

最佳实践建议

基于本次经验，我们总结出以下升级最佳实践：

1. 预先检查：升级前全面检查节点状态，确保没有残留的维护模式标签
2. 资源调整：提前调整关键组件（如Prometheus）的资源配额
3. 监控准备：准备实时监控手段，及时发现和处理问题
4. 分阶段操作：对于特殊配置的虚拟机，考虑分阶段手动处理
5. 日志收集：升级过程中持续收集日志，便于问题诊断

未来改进方向

Harvester升级机制还可以在以下方面继续优化：

1. 增强对特殊配置虚拟机（PCI直通、USB设备、vGPU等）的生命周期管理
2. 改进预排空脚本的健壮性，防止跳过关键步骤
3. 自动处理Longhorn锁问题，减少人工干预
4. 优化资源预估和自动调整机制，避免组件OOM

总结

Harvester 1.5.0的升级体验展示了该项目的成熟度提升。通过理解升级过程中的各种问题及其解决方案，运维人员可以更顺利地完成版本迭代。本文记录的经验和教训不仅适用于1.5.0版本，也为未来版本的升级提供了有价值的参考框架。