Homelab项目中Gitea服务DNS解析问题排查与解决

问题背景

在Homelab项目的生产环境部署中，用户遇到了Gitea服务及其依赖组件(Dex、Woodpecker、Renovate)处于降级状态的问题。核心错误表现为Gitea容器无法启动，日志显示数据库连接失败，具体错误为"dial tcp: lookup gitea-postgresql-ha-pgpool.gitea.svc.cluster.local: no such host"。

问题分析

初始症状

Gitea服务无法正常启动，其初始化容器反复尝试连接数据库失败。错误信息表明系统无法解析PostgreSQL高可用集群的DNS名称。这个问题同时影响了依赖Gitea的其他服务，包括Woodpecker、Dex和Renovate。

根本原因

经过排查，发现问题出在Kubernetes集群内部的DNS解析机制上。具体表现为：

1. 默认的dnsPolicy: ClusterFirst配置未能正常工作
2. CoreDNS服务无法解析完整的服务域名(gitea-postgresql-ha-pgpool.gitea.svc.cluster.local)
3. 短域名形式(gitea-postgresql-ha-pgpool.gitea.svc)可以正常解析

解决方案

临时解决方案

通过修改Gitea部署的DNS配置，手动指定nameserver和搜索域：

dnsConfig:
  nameservers:
    - 10.43.0.10  # CoreDNS服务地址
  options:
    - name: ndots
      value: '5'
  searches:
    - svc.cluster.local
    - cluster.local
dnsPolicy: None

这个配置强制Pod使用集群的CoreDNS服务，并设置了适当的搜索域，解决了服务发现的问题。

最终解决方案

用户最终采用了更彻底的解决方法：

1. 放弃原有域名环境
2. 申请全新域名
3. 从零开始重新部署整个Homelab环境

这种方法确保了干净的DNS环境，避免了历史配置可能带来的各种隐性问题。

经验总结

1. Kubernetes中的服务发现依赖于CoreDNS的正常工作，当遇到类似问题时，首先应该检查DNS解析是否正常。

2. 对于复杂的服务依赖关系，基础服务(如数据库)的问题会级联影响上层应用，合理的排查顺序是从底层服务开始。

3. 生产环境中，DNS配置问题往往与历史遗留配置有关，全新环境部署有时比修复现有问题更高效可靠。

4. 在Homelab这类复杂系统中，各组件的依赖关系需要清晰了解，如本案例中多个服务都依赖于Gitea的正常运行。

最佳实践建议

1. 部署前确保Kubernetes集群的CoreDNS服务正常工作，可以通过创建测试Pod验证服务发现功能。

2. 对于关键服务，考虑在部署配置中明确指定DNS策略，而不是完全依赖默认设置。

3. 保持Homelab环境的整洁，避免不同部署间的配置冲突，特别是网络和DNS相关配置。

4. 建立完善的监控系统，及时发现并解决服务降级问题，防止问题扩散影响整个系统。