Harvester项目升级过程中节点卡在Pre-drained状态的技术分析

问题背景

在Harvester v1.4.1升级至v1.4.2-rc1版本的过程中，技术人员发现了一个关键问题：当集群节点采用操作系统盘与数据盘分离的配置时，升级流程会在第一个节点处停滞在"Pre-drained"状态。这一现象在三节点集群环境中尤为明显，严重影响了生产环境的升级体验。

问题现象

升级过程中，系统界面显示第一个节点长时间停留在"Pre-drained"阶段，无法继续后续升级步骤。同时，集群中多个关键Pod处于Pending状态，包括rancher、harvester-webhook、virt-api和virt-controller等重要组件。这些组件的异常状态直接影响了整个集群的正常运行。

根因分析

通过深入排查日志和技术分析，我们发现问题的核心原因在于KubeVirt组件的Pod调度策略变更：

1. 节点角色限制：从KubeVirt v1.3.0开始，virt-api和virt-controller组件新增了严格的节点亲和性规则，要求这些Pod必须运行在控制平面节点上。而在v1.2.2版本中则没有此限制。

2. Pod中断预算(PDB)冲突：当尝试排空第一个控制平面节点时，系统无法安全地驱逐这些关键Pod，因为这样做会违反它们的中断预算策略(PDB)，导致升级流程停滞。

3. 集群拓扑影响：在测试环境中，第二个和第三个节点被配置为纯工作节点，无法自动提升为控制平面节点。这种配置使得集群在功能上更类似于单节点集群，无法满足KubeVirt新版本对多控制平面节点的要求。

技术解决方案

针对这一问题，技术团队提出了以下解决方案：

1. KubeVirt配置调整：通过在KubeVirt自定义资源(CR)中显式设置.spec.infra.nodePlacement: {}参数，可以覆盖默认的节点亲和性规则，恢复v1.2.2版本的行为模式。

2. 紧急处理方案：对于已经遇到此问题的环境，可以临时删除virt-api-pdb和virt-controller-pdb这两个Pod中断预算资源，使升级流程能够继续。但这种方法仅建议在紧急情况下使用。

3. 长期架构建议：对于生产环境，建议采用至少三个控制平面节点的集群架构，以确保高可用性和平滑升级体验。

验证结果

该问题已在v1.4.2-rc2版本中得到修复。验证测试表明：

1. 在操作系统盘与数据盘分离的三节点环境中，升级流程能够顺利完成，不再出现节点卡在"Pre-drained"状态的情况。

2. 所有关键系统Pod都能正常调度和运行，集群功能完整。

3. 通过文件系统检查确认升级过程中没有造成存储层损坏或数据丢失。

最佳实践建议

基于此次问题的经验，我们建议Harvester用户：

1. 在规划集群架构时，充分考虑控制平面节点的高可用性配置。

2. 执行重大版本升级前，仔细阅读版本变更说明，特别是涉及核心组件如KubeVirt的版本更新。

3. 对于生产环境，建议先在测试环境中验证升级流程，确保兼容性和稳定性。

4. 定期检查集群中关键组件的Pod调度状态，及时发现潜在的资源调度问题。

通过这次问题的分析和解决，Harvester项目在节点升级流程的稳定性和兼容性方面得到了显著提升，为后续版本的大规模部署奠定了更坚实的基础。