Harvester集群节点异常Cordoned状态问题分析与解决

问题背景

在Harvester 1.5.0版本的四节点集群环境中，管理员在尝试移除并重新添加dmz02节点时遇到了异常状态问题。该节点在重新加入集群后，虽然能短暂进入Ready状态，但会在大约5分钟后自动转为Cordoned状态，导致运行在其上的虚拟机被迁移到其他节点，Ceph RBD Pods也被移除。

问题现象分析

通过深入分析集群状态，发现以下关键现象：

1. 状态异常循环：节点在手动Uncordon后能恢复Active状态，但5分钟后又会自动转为Cordoned
2. 资源不匹配：集群中实际有4个节点，但存在8个Machine对象，明显不符合1:1的正常比例
3. 残留对象：旧dmz02节点的Machine对象(custom-a3b368e81759)处于Deleting状态但未能完全删除

根本原因

问题的核心在于集群管理系统的状态不一致：

1. Machine对象残留：旧dmz02节点的Machine对象未能完全清理，导致新加入的节点被视为异常
2. 集群状态不一致：Cluster对象的ControlPlaneReady和WorkerMachinesReady状态显示配置异常
3. 删除流程中断：可能由于强制删除节点(kubectl delete node)导致正常的删除流程未能完成

解决方案

经过技术验证，推荐以下解决步骤：

1. 清理残留Machine对象：

   kubectl -n fleet-local delete machines.cluster.x-k8s.io <异常Machine名称>
   

2. 完全移除问题节点：

   • 通过Harvester UI或kubectl删除节点
   • 等待节点及其关联资源完全移除

3. 重新添加节点：

   • 确认集群中只有3个正常节点(1,3,4)和对应的3个Machine对象
   • 重新安装并加入dmz02节点

技术要点

1. Harvester节点管理机制：

   • 每个节点应有且仅有一个对应的Machine对象
   • Machine对象状态应与节点实际状态保持一致

2. 删除节点最佳实践：

   • 避免直接使用kubectl delete node强制删除
   • 应通过Harvester UI或正规流程删除节点
   • 确保删除过程完成后再进行其他操作

3. 状态监控：

   • 定期检查Cluster和Machine对象状态
   • 关注ControlPlaneReady和WorkerMachinesReady等关键状态

预防措施

1. 操作规范：

   • 节点维护操作应遵循标准流程
   • 避免在删除过程中中断操作

2. 状态检查：

   • 在进行节点操作前，先检查集群整体状态
   • 确认无残留资源后再进行新操作

3. 监控告警：

   • 设置对Machine对象数量的监控
   • 对异常状态设置告警

总结

Harvester集群节点状态异常往往源于底层资源管理对象的不一致。通过系统性地清理残留资源、遵循标准操作流程，可以有效解决这类问题。对于生产环境，建议在维护窗口期进行节点操作，并做好完整的状态检查和备份工作。