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

问题背景

在Harvester虚拟化管理平台的版本升级过程中，用户报告了一个关键问题：当从v1.4.1版本升级到v1.4.2-rc1版本时，升级流程会在第一个节点卡在"Pre-drained"状态。这一问题特别出现在三节点集群环境中，且这些节点采用了操作系统盘和数据盘分离的存储配置方式。

问题现象

升级过程中，系统显示第一个节点长时间停留在"Pre-drained"阶段，无法继续后续的升级流程。同时，集群中多个关键Pod（包括rancher、harvester-webhook、virt-api和virt-controller等）处于Pending状态，导致整个系统功能受限。

根本原因分析

经过深入调查，发现问题的核心在于KubeVirt组件的行为变更：

1. KubeVirt版本差异：v1.4.1使用的是KubeVirt v1.2.2，而v1.4.2-rc1升级到了KubeVirt v1.3.1。新版本引入了对Pod部署位置的严格限制。

2. 节点亲和性变更：KubeVirt v1.3.1为virt-api和virt-controller部署添加了严格的节点亲和性规则，要求这些Pod必须运行在控制平面节点上。具体表现为：

   • 必须运行在带有node-role.kubernetes.io/control-plane或node-role.kubernetes.io/master标签的节点上
   • 优先选择没有node-role.kubernetes.io/worker标签的节点

3. Pod中断预算(PDB)冲突：当尝试排空第一个控制平面节点时，系统无法安全地驱逐virt-api和virt-controller Pod，因为这会导致违反它们的Pod中断预算策略。

4. 多节点集群的特殊性：在配置为单控制平面+多工作节点的集群环境中，这一问题尤为突出，因为virt-api和virt-controller Pod只能运行在唯一的控制平面节点上。

解决方案

开发团队提出了两种解决方案：

1. 临时解决方案：手动删除harvester-system命名空间中的virt-api-pdb和virt-controller-pdb Pod中断预算对象，允许升级流程继续。但这只是一个应急措施，不推荐在生产环境中使用。

2. 永久解决方案：通过修改Harvester的Helm chart，在KubeVirt自定义资源中显式设置.spec.infra.nodePlacement: {}配置项。这一变更可以恢复KubeVirt v1.2.2版本的行为，取消对Pod部署位置的限制。

验证结果

该修复已在v1.4.2-rc2版本中得到验证，确认解决了升级过程中节点卡住的问题。测试环境采用三节点物理机集群，操作系统盘和数据盘分离的配置，升级流程顺利完成，所有节点都能正确完成升级过程。

技术启示

这一案例展示了基础设施软件升级过程中可能遇到的兼容性问题，特别是当底层组件（如KubeVirt）的行为发生变更时。对于集群管理软件而言，需要特别注意：

1. 组件版本升级可能引入不兼容的默认行为变更
2. 多节点集群中资源调度和Pod分布的策略需要全面考虑
3. 升级流程必须能够处理各种集群配置场景
4. 为关键系统组件提供配置灵活性非常重要

Harvester团队通过这一问题的解决，进一步完善了产品的升级健壮性，为后续版本的大规模部署提供了更好的保障。