Harvester升级故障排查：1.4.0至1.4.1版本升级卡死问题解析

问题现象

在Harvester虚拟化管理平台从1.4.0版本升级至1.4.1版本的过程中，部分用户遇到了升级进程长时间卡顿的情况。具体表现为：

1. 首次升级尝试时，进度条停滞超过48小时无响应
2. 强制删除升级对象后，再次尝试升级时出现关键错误提示：

   admission webhook "validator.harvesterhci.io" denied the request: 
   managed chart hvst-upgrade-rqqrp-upgradelog-operator is not ready, 
   please wait for it to be ready.
   

根本原因分析

该问题源于升级过程中遗留的CRD（Custom Resource Definition）资源未完全清理。当升级流程被异常中断时，系统会残留名为hvst-upgrade-rqqrp-upgradelog-operator的managedchart资源对象，该对象属于Harvester的升级日志组件。

由于Kubernetes的准入控制器会持续校验该资源状态，而残留对象又无法自动恢复，导致后续升级尝试被webhook强制拦截。

解决方案

标准处理流程

1. 通过kubectl检查残留资源：

   kubectl get managedchart -A | grep upgradelog-operator
   

2. 手动清理残留对象（注意替换实际对象名称）：

   kubectl delete managedchart hvst-upgrade-rqqrp-upgradelog-operator -n harvester-system
   

3. 重新发起升级时，在界面中取消勾选"Upgrade Log"选项

预防性建议

• 在升级前确保集群有足够的资源余量（至少20%CPU/内存空闲）
• 使用kubectl get pods -A确认所有系统组件处于健康状态
• 建议在业务低峰期执行升级操作

技术深度解读

Harvester的升级机制基于以下关键技术栈：

1. Fleet管理：通过Rancher Fleet管理集群组件生命周期
2. Helm Chart：所有组件以Helm Chart形式部署
3. CRD控制：使用Custom Resource管理升级状态

当升级中断时，系统会保留中间状态资源以便故障恢复。但某些情况下（如资源不足或网络问题），这些中间状态资源可能无法自动清理，需要人工介入。

最佳实践

1. 建立升级前检查清单：

   • 确认etcd集群健康状态
   • 检查长期存储卷的可用空间
   • 验证网络连接稳定性

2. 升级过程监控要点：

   • 关注cattle-system和harvester-system命名空间的Pod状态
   • 实时查看升级Job日志：kubectl logs -f <upgrade-pod>

3. 回退方案：

   • 保留升级前的虚拟机快照
   • 准备1.4.0版本的ISO镜像备用

后续版本改进

Harvester开发团队已在后续版本中优化了以下方面：

1. 增加升级超时自动回滚机制
2. 完善资源清理流程
3. 增强升级状态可视化展示

建议用户关注官方发布说明，及时升级到最新稳定版本以获得最佳体验。