Infisical项目中的Kubernetes DNS解析问题分析与解决方案

问题背景

在使用Infisical项目进行数据库迁移时，开发人员遇到了一个典型的Kubernetes DNS解析异常问题。当应用尝试通过内部服务名称pg-infisical-rw.infisical.svc.cluster.local连接PostgreSQL数据库时，DNS解析意外地返回了CDN服务商的公共IP地址，而非预期的集群内部IP地址。

问题现象

应用配置了标准的Kubernetes内部服务FQDN(完全限定域名)作为数据库连接地址：

postgresql://$(DB_USER):$(DB_PASSWORD)@pg-infisical-rw.infisical.svc.cluster.local:5432/pg-infisical?sslmode=verify-ca&sslrootcert=/etc/custom-certs/postgres-ca.crt

然而实际连接尝试却指向了CDN服务商的公共IP地址：

• IPv4地址：104.21.13.94
• IPv6地址：2606:4700:3033::ac43:a7ec

这导致连接超时错误(ETIMEDOUT)，数据库迁移任务无法完成。

根本原因分析

经过深入排查，发现问题根源在于Kubernetes节点的DNS解析配置。具体表现为：

1. DNS搜索域配置问题：Kubernetes节点上的/etc/resolv.conf文件中配置了搜索域(search domain)，导致DNS解析时自动追加了不必要的域名后缀。

2. FQDN解析异常：当使用完整的pg-infisical-rw.infisical.svc.cluster.local时，由于搜索域的干扰，DNS解析过程出现了异常，最终返回了错误的公共IP地址。

3. 短域名工作正常：相比之下，使用较短的pg-infisical-rw.infisical.svc却能正常解析到内部服务IP，这进一步验证了搜索域配置是问题的关键。

解决方案

针对这一问题，可以采取以下几种解决方案：

方案一：修改DNS解析配置

1. 编辑节点的/etc/resolv.conf文件
2. 移除或调整搜索域配置
3. 确保DNS解析优先考虑完整FQDN

方案二：使用短域名替代

在连接字符串中使用较短的内部服务名称：

pg-infisical-rw.infisical.svc

这种方式避免了与搜索域的冲突，在测试中被证实有效。

方案三：明确指定搜索域顺序

在Pod配置中，可以通过dnsConfig明确指定DNS策略：

dnsConfig:
  searches:
    - infisical.svc.cluster.local
    - svc.cluster.local
    - cluster.local
  options:
    - name: ndots
      value: "5"

预防措施

为避免类似问题再次发生，建议：

1. 统一命名规范：在Kubernetes集群内部统一使用短域名或FQDN中的一种
2. DNS策略测试：部署前测试DNS解析结果是否符合预期
3. 文档记录：将正确的连接字符串格式记录在项目文档中
4. 健康检查：在应用启动脚本中加入DNS解析验证步骤

总结

Kubernetes环境中的DNS解析问题看似简单，但可能引发严重的连接异常。通过这个案例，我们了解到：

1. 完整FQDN和短域名在Kubernetes环境中的解析行为可能存在差异
2. 节点的DNS搜索域配置会显著影响内部服务发现
3. 在配置数据库连接等关键连接时，必须验证DNS解析结果

对于Infisical这类依赖数据库连接的项目，确保DNS解析可靠性是保障系统稳定性的重要一环。开发者和运维团队应当充分理解Kubernetes的DNS工作机制，并在不同环境中进行充分测试。