Harvester 项目中升级控制器处理DNS解析错误的优化

问题背景

在Harvester项目的升级过程中，升级控制器负责清理不再需要的容器镜像。这一过程需要从升级仓库VM中获取镜像列表，但在某些情况下会出现DNS解析错误，导致镜像清理失败。

问题现象

在单节点集群的升级过程中，特别是在升级的最后阶段，当控制器重启升级仓库VM以获取镜像列表时，Kubernetes服务可能尚未更新相关端点。此时，尝试解析upgrade-repo-hvst-upgrade-xxxx.harvester-system域名时会出现"no such host"错误。

错误日志示例如下：

Unable to cleanup images: Get "http://upgrade-repo-hvst-upgrade-nv76q.harvester-system/...": dial tcp: lookup upgrade-repo-hvst-upgrade-nv76q.harvester-system on 10.53.0.10:53: no such host

技术分析

该问题本质上是一个DNS解析错误，具体表现为Golang标准库中的notFoundError类型错误。在单节点集群环境中，当节点在升级后重启时，DNS服务可能尚未完全恢复所有记录，而此时Harvester控制器已经开始请求仓库服务。

从技术实现角度看，Golang的net包中定义了这类错误：

var errNoSuchHost = &notFoundError{"no such host"}

当DNS查询失败时，系统会返回一个DNSError结构体，其中IsNotFound字段被设置为true，表示这是一个"not found"类型的错误。

解决方案

针对这一问题，开发团队采取了以下解决方案：

1. 将DNS解析错误添加到重试机制的错误列表中
2. 增强错误处理逻辑，使控制器能够识别并正确处理这类临时性DNS问题
3. 实现自动重试机制，在遇到这类错误时不会立即失败，而是等待服务完全恢复

验证方法

该修复的验证方法相对简单直接：

1. 执行Harvester版本升级操作
2. 升级完成后检查Harvester Pod的日志
3. 确认日志中不再出现包含"lookup...no such host"关键字的警告信息

技术意义

这一修复不仅解决了特定场景下的问题，还增强了系统在临时性网络问题下的健壮性。它体现了分布式系统中一个重要的设计原则：对临时性故障应当有自动恢复机制，而不是立即失败。

在云原生环境中，服务之间的依赖关系复杂，网络状况多变，这类针对临时性故障的容错处理尤为重要。通过将DNS解析错误纳入重试机制，系统能够更好地应对服务启动顺序、网络延迟等现实世界中的问题。

总结

Harvester项目团队通过分析升级过程中出现的DNS解析问题，识别出在单节点集群升级场景下的特定故障模式，并实施了针对性的修复。这一改进提升了升级过程的可靠性，特别是在资源受限或网络条件不理想的部署环境中。对于使用Harvester的用户来说，这意味着更稳定、更可靠的升级体验。