Harvester项目升级失败问题分析：managed chart未就绪的解决方案

问题背景

在Harvester 1.4.0版本升级至1.4.1的过程中，部分用户遇到了升级失败的情况，系统提示"admission webhook 'validator.harvesterhci.io' denied the request: managed chart harvester is not ready, please wait for it to be ready"错误。这个问题主要与Harvester的托管图表(managed chart)状态异常有关。

问题分析

通过深入分析，我们发现导致升级失败的核心原因有两个：

1. 网络控制器Webhook资源限制问题：用户曾修改过harvester-network-webhook的内存限制，导致资源规格与系统预期不符。虽然用户已恢复原始配置，但系统仍记录了变更历史。

2. Windows系统代理升级计划配置异常：在cattle-system命名空间下的system-agent-upgrader-windows Plan资源中，缺少了关键的securityContext配置，导致系统无法识别其为有效就绪状态。

解决方案

针对网络控制器Webhook问题

如果用户曾修改过harvester-network-webhook的资源限制，需要确保恢复为默认配置：

resources:
  limits:
    cpu: 200m
    memory: 256Mi
  requests:
    cpu: 10m
    memory: 64Mi

针对Windows系统代理升级计划问题

需要通过以下步骤修复配置：

1. 使用kubectl编辑问题资源：

kubectl edit plan -n cattle-system system-agent-upgrader-windows

2. 确保spec.upgrade部分包含正确的securityContext配置：

upgrade:
  securityContext:
    windowsOptions:
      hostProcess: true
      runAsUserName: NT AUTHORITY\SYSTEM

3. 保存退出后，系统会自动重新评估资源状态。

技术原理

Harvester使用Fleet管理系统组件，通过Bundle和BundleDeployment资源来管理集群状态。当这些资源的状态不是"Ready"时，系统会阻止升级操作以确保稳定性。在本案例中：

• Bundle资源会监控集群中实际资源与期望状态的差异
• 任何手动修改都会导致系统检测到"Modified"状态
• 升级验证webhook会严格检查所有托管组件是否处于预期状态

最佳实践建议

1. 避免直接修改托管资源：对Harvester管理的资源进行修改时，建议通过官方提供的配置接口进行。

2. 升级前检查组件状态：执行升级前，建议先检查所有Bundle资源的状态：

kubectl get bundle -A

3. 了解系统恢复机制：当遇到类似问题时，可以通过添加diff.comparePatches配置来忽略特定变更。

4. 监控关键组件：特别关注harvester-network-webhook等关键组件的资源使用情况，避免因OOM等问题导致状态异常。

总结