Harvester项目中的升级控制器DNS解析问题分析与解决方案

问题背景

在Harvester v1.4.1到v1.5.0的升级过程中，我们观察到一个关键的系统行为异常。当升级控制器尝试清理旧版本容器镜像时，系统日志中频繁出现DNS解析失败的错误信息。这个错误表现为无法解析升级仓库虚拟机的域名，具体错误信息为"no such host"。

问题现象

在升级过程的最后阶段，当控制器尝试获取旧版本镜像列表以进行清理时，系统会记录如下警告信息：

Unable to cleanup images: Get "http://upgrade-repo-hvst-upgrade-nv76q.harvester-system/harvester-iso/bundle/harvester/images-lists-archive/v1.4.1/image_list_all.txt": dial tcp: lookup upgrade-repo-hvst-upgrade-nv76q.harvester-system on 10.53.0.10:53: no such host

这个问题在单节点集群环境中尤为常见，特别是在节点升级后重启的阶段。

技术分析

根本原因

深入分析后发现，这个问题源于系统组件间的时序依赖关系：

1. 在单节点集群升级的最后阶段，控制器会重启升级仓库虚拟机以获取镜像列表
2. 当虚拟机恢复运行后，Kubernetes服务可能尚未及时更新相关的Endpoint信息
3. 此时对upgrade-repo-hvst-upgrade-<随机ID>.harvester-system的DNS查询会返回"no such host"错误

从技术实现角度看，这个错误是Go语言网络库中的标准DNS错误类型，具体定义为errNoSuchHost，属于notFoundError类别。

影响范围

这个问题主要影响：

• 单节点部署的Harvester集群
• 系统升级过程中的镜像清理阶段
• 不会影响核心升级流程，但可能导致旧版本镜像清理不完全

解决方案

基于上述分析，我们确定了以下解决方案：

1. 将DNS解析错误(no such host)添加到系统的重试机制中
2. 在升级控制器中实现更健壮的错误处理逻辑
3. 增加对临时性DNS故障的容错能力

具体实现上，我们修改了错误处理逻辑，使系统能够识别这类临时性DNS故障并进行自动重试，而不是直接记录错误日志。

验证与测试

该修复已在Harvester v1.5.0-rc2版本中验证通过。测试方法包括：

1. 部署单节点v1.4.2集群
2. 执行升级到v1.5.0-rc2的操作
3. 监控系统日志确认不再出现DNS解析错误
4. 验证镜像清理功能正常工作

测试结果表明，系统现在能够正确处理升级过程中可能出现的临时性DNS解析问题，确保了升级流程的顺利完成。

技术启示

这个问题给我们带来了几个重要的技术启示：

1. 在分布式系统中，组件启动顺序和依赖关系需要特别关注
2. 临时性网络问题应该通过重试机制而非错误日志来处理
3. 单节点环境下的时序问题往往比多节点环境更为微妙
4. 系统升级过程中的资源清理需要更强的容错能力

通过这个案例，我们进一步提升了Harvester升级系统的健壮性，为未来版本的稳定性奠定了基础。