Harvester升级过程中容器镜像拉取问题分析与解决方案

问题背景

在Harvester从v1.4.2版本升级到v1.5.0-rc4版本的过程中，部分用户遇到了升级流程卡在"下载升级镜像"阶段的问题。具体表现为升级日志收集组件fluentbit的Pod处于ImagePullBackOff状态，无法正常启动。

问题现象

升级过程中主要出现以下两种异常现象：

1. 升级流程停滞在"Download Upgrade Image"阶段，进度条无变化
2. 检查集群状态发现upgradelog-infra-fluentbit Pod处于ImagePullBackOff状态

根本原因分析

经过深入排查，发现该问题主要由以下几个因素导致：

1. 镜像拉取失败：升级过程中需要拉取三个关键容器镜像，包括fluent/fluent-bit:2.1.8、ghcr.io/kube-logging/fluentd:v1.15-ruby3和ghcr.io/kube-logging/config-reloader:v0.0.5。其中fluent-bit镜像来自公共镜像仓库，在某些网络环境下可能出现拉取失败。

2. 版本同步机制：当升级流程在初始阶段卡住时，Harvester内置的版本同步器会定期检查并清理无效的版本记录，导致出现"versions.harvesterhci.io not found"的错误提示。

3. 环境因素：虽然集群具有互联网连接能力，但可能由于网络策略限制或镜像仓库临时不可访问，导致特定镜像拉取失败。

解决方案

针对这一问题，我们推荐以下解决方案：

1. 手动清理旧镜像：

   • 登录到Harvester节点
   • 执行命令删除已存在的三个相关镜像
   • 重新触发升级流程

2. 网络环境检查：

   • 确保节点能够正常访问公共镜像仓库和GitHub容器注册表
   • 检查网络策略是否允许出站连接到相关镜像仓库

3. 升级流程优化：

   • 在升级前预先拉取所需镜像
   • 考虑使用本地镜像仓库缓存关键镜像

技术建议

对于生产环境升级，我们建议：

1. 在非业务高峰期执行升级操作
2. 提前验证网络连通性，特别是对关键镜像仓库的访问
3. 考虑搭建本地镜像仓库作为缓存，减少对外部仓库的依赖
4. 保留足够的系统资源，确保升级流程顺利进行

总结

Harvester升级过程中的镜像拉取问题通常与环境配置相关，通过合理的预处理和网络配置可以避免大多数类似问题。对于关键业务系统，建议在测试环境充分验证升级流程后再在生产环境实施。