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

问题现象

在Harvester 1.5.0版本的4节点集群环境中，当管理员尝试移除并重新加入dmz02节点时，发现该节点虽然能短暂进入Ready状态，但会在大约5分钟后自动转为Cordoned状态。这种异常行为导致：

1. Ceph RBD Pods被自动移除
2. 运行在该节点上的虚拟机被迁移到其他节点
3. 需要人工干预才能短暂恢复Active状态

根本原因分析

通过深入分析集群状态，发现问题的核心在于机器(Machine)资源与节点(Node)的映射关系异常。具体表现为：

1. 机器资源冗余：正常情况下，每个节点应该对应一个Machine资源，但该集群中存在多个Machine资源同时映射到dmz02节点
2. 删除不彻底：之前强制删除节点时(kubectl delete node)，未等待集群完成Machine资源的清理流程
3. 控制平面状态异常：Cluster资源显示有机器处于"Deleting"状态超过15分钟，阻塞了正常的集群操作

技术细节

异常状态机分析

1. Machine资源状态：

   • custom-a3b368e81759：处于Deleting状态超过24小时
   • custom-8019c31ceff0/custom-91357ad65ba6：处于Provisioning状态
   • 多个Machine同时映射到dmz02节点

2. 集群协调机制：

   • Harvester基于Cluster API实现节点生命周期管理
   • 残留的Machine资源导致控制器持续尝试协调节点状态
   • 5分钟间隔是默认的协调周期

关键错误信息

在Cluster资源状态中观察到以下关键报错：

* Machine custom-a3b368e81759:
  * Deleting: Machine deletion in progress since more than 15m, stage: WaitingForPreTerminateHook

解决方案

完整修复步骤

1. 清理残留资源：

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

2. 彻底移除问题节点：

   • 通过Harvester UI或kubectl删除节点
   • 确认节点和关联Machine资源都已完全清除

3. 重新加入节点：

   • 确保集群中只有3个正常节点(1,3,4)和对应的3个Machine
   • 使用标准流程重新添加dmz02节点

操作建议

1. 避免强制删除：始终通过Harvester UI或正确流程移除节点
2. 状态验证：在操作前后检查以下资源状态：

   kubectl get nodes
   kubectl -n fleet-local get machines.cluster.x-k8s.io
   kubectl get cluster -A
   

3. 等待操作完成：节点删除可能需要较长时间，需耐心等待所有资源清理完成

预防措施

1. 监控Machine资源：定期检查Machine与Node的对应关系
2. 维护窗口期：在集群负载较低时执行节点维护操作
3. 日志收集：操作前生成支持包，便于问题诊断
4. 版本管理：保持Harvester版本更新，修复已知问题

总结

Harvester集群节点状态异常通常源于底层Machine资源的状态不一致。通过系统性地清理残留资源、确保资源映射关系正确，可以有效解决这类问题。关键是要理解Harvester基于Cluster API的架构原理，遵循正确的节点维护流程，避免强制操作导致状态不一致。