Harvester项目升级故障分析与恢复实战

升级过程遭遇的挑战

在Harvester集群从v1.3.1升级到v1.3.2版本的过程中，我们遇到了一个典型的升级卡死问题。系统在"Images preloaded"阶段停滞不前，随后在节点排水阶段也出现了异常。这种情况在复杂的生产环境中并不罕见，但需要谨慎处理以避免数据丢失或集群不可用。

故障现象深度分析

最初尝试升级时，系统在节点1的"Post Draining"阶段卡住。管理员按照官方文档执行了升级重启操作，将版本回退到v1.3.1并重新创建v1.3.2版本以触发升级。然而，系统报告了不一致的状态：虽然显示有v1.4.0的可用更新，但操作系统镜像仍停留在v1.3.1版本。

通过检查集群状态，发现节点间存在Kubernetes版本不一致的情况：

• 节点1：v1.28.12+rke2r1
• 节点2和3：v1.27.13+rke2r1

这种版本分化是导致升级失败的关键因素之一。CAPI控制器日志中频繁出现的TLS握手错误进一步表明集群内部通信已出现问题。

恢复方案设计与实施

面对这一复杂情况，我们采取了分阶段恢复策略：

第一阶段：集群状态评估

1. 停止所有运行中的虚拟机
2. 检查各节点状态和角色分配
3. 分析RKE2和etcd日志确认集群健康状况

第二阶段：节点重置与重新加入

1. 安全停止故障升级过程
2. 按照规范删除问题节点
3. 发现节点自动升级到不兼容的Kubernetes版本(v1.28.12)
4. 使用v1.3.2网络安装ISO重新部署节点

第三阶段：RKE2集群重置

当发现etcd失去法定人数后，执行了关键恢复步骤：

1. 在剩余的健康节点上执行RKE2集群重置
2. 轮换所有集群证书
3. 彻底清理遗留的集群资源(rkebootstraps, custommachines等)
4. 重新加入新节点，确保使用新的主机名避免冲突

后续升级验证

成功恢复基础集群后，我们继续完成了版本升级路径：

1. 从v1.3.2平稳升级到v1.4.0
2. 继续升级到v1.4.1版本

值得注意的是，v1.4.1版本在系统响应性方面有显著改善，这验证了恢复操作的成功。

经验总结与最佳实践

通过这次故障处理，我们总结了以下重要经验：

1. 升级前检查至关重要：必须运行升级预检查脚本，确认集群健康状况
2. 升级中断处理：一旦升级进入节点排水阶段，不应尝试重启升级过程
3. 版本兼容性：Harvester不支持从v1.3.2回退到v1.3.1的降级操作
4. 恢复策略：RKE2集群重置是恢复etcd法定人数的有效方法，但需配合完整备份
5. 节点管理：重新加入节点时建议使用新的主机名和管理IP，避免残留状态影响

这次实战经验证明，即使面对复杂的升级故障，通过系统化的分析和谨慎的操作，仍然可以成功恢复集群并完成升级目标。对于生产环境，建立完善的备份机制和详细的升级预案是确保业务连续性的关键。