Harvester集群升级过程中节点卡在pre-drained状态的分析与解决

在Harvester v1.4.0升级至v1.4.1版本的过程中，用户遇到了首个节点在pre-drained阶段停滞的问题。这种情况在长期运行的集群（超过430天）中尤为值得关注，本文将深入分析问题原因并提供解决方案。

问题现象

升级过程中，第一个节点虽然显示已升级至v1.30.7+rke2r1版本，但状态却持续停留在"Cordoned"状态。用户尝试了以下常规解决方法：

1. 删除Longhorn instance-manager的PodDisruptionBudget(PDB)
2. 手动解除节点封锁(uncordon)使Longhorn卷恢复健康状态
3. 重新封锁节点(cordon)

但这些操作均未能使升级流程继续推进。

根本原因分析

通过检查集群状态发现，问题实际上源于Kubernetes控制平面组件的就绪检查未通过。具体表现为kube-controller-manager和kube-scheduler两个关键组件的健康探针(probe)未能响应，导致升级流程无法继续。

这种情况在长期运行的集群中可能出现，特别是当：

• 控制平面组件积累了过多未处理请求
• 系统资源长时间运行后出现碎片化
• 组件配置在多次升级后存在不一致

解决方案

针对此问题，最有效的解决方法是重启受影响的控制平面组件：

1. 首先确认具体是哪些组件未通过健康检查
2. 通过kubectl删除对应的pod，让Kubernetes自动重建它们
3. 监控组件重启后的日志，确认无异常错误
4. 等待健康检查自动通过

这种方法相比直接操作节点或存储系统更为直接有效，因为它直接解决了控制平面组件的就绪问题，而不是处理表面现象。

预防建议

为避免类似问题在未来升级中出现，建议：

1. 在升级前确保所有控制平面组件健康状态良好
2. 考虑定期重启长期运行的控制平面组件
3. 升级前检查系统资源使用情况，确保有足够余量
4. 监控关键组件的日志，提前发现潜在问题

通过理解这一问题的本质和解决方法，用户可以更顺利地完成Harvester集群的升级过程，并提高集群的长期稳定性。