OKD项目中DNS解析问题的排查与解决

问题背景

在OKD 4.15集群部署完成后，管理员发现认证服务和Insights服务出现异常。具体表现为：

1. 认证服务(Authentication)处于降级状态，错误信息显示TLS证书验证失败，提示证书仅对*.apps.oc.domain.tld、*.oc.domain.tld和oc.domain.tld有效，而不包含login.domain.tld

2. Insights服务不可用，同样出现TLS证书验证问题，提示证书对console.redhat.com无效

问题分析

通过检查集群日志，发现更根本的问题在于DNS解析行为异常。当集群尝试解析外部域名如login.domain.tld或infogw.api.openshift.com时，系统会自动追加集群的基础域名oc.domain.tld，形成错误的查询格式如login.domain.tld.oc.domain.tld。

这种异常行为会导致：

• 外部服务无法正确解析
• TLS证书验证失败，因为实际访问的域名与证书不匹配
• 关键服务如认证和监控功能受损

根本原因

深入排查后发现，问题源于主机系统的/etc/resolv.conf配置文件中存在search参数设置。该参数被配置为oc.domain.tld，导致所有DNS查询都会自动追加这个后缀。

在Linux系统中，/etc/resolv.conf的search参数用于指定DNS查询时自动尝试的域名后缀列表。当这个参数包含集群基础域名时，所有DNS查询都会先尝试追加该后缀，造成外部域名解析失败。

解决方案

1. 编辑/etc/resolv.conf文件
2. 注释或删除包含search oc.domain.tld的行
3. 确保只保留必要的nameserver配置

修改后的/etc/resolv.conf示例：

# Generated by NetworkManager
nameserver 8.8.8.8

验证与效果

修改完成后：

• 外部域名能够正确解析，不再追加集群基础域名
• 认证服务恢复正常运行状态
• Insights服务能够正确连接到Red Hat控制台
• 所有依赖外部域名解析的服务恢复正常

经验总结

在部署OKD/OpenShift集群时，需要特别注意主机系统的DNS配置。search参数虽然在某些内部网络环境中很有用，但在混合云或需要访问大量外部服务的场景下可能造成问题。建议：

1. 在集群部署前检查所有节点的DNS配置
2. 对于需要访问外部服务的集群，谨慎使用search参数
3. 考虑使用更精细化的DNS配置，如为特定域名配置单独的解析规则

这个问题也提醒我们，在遇到证书验证失败时，不仅要检查证书本身的有效性，还应该排查实际的网络连接和域名解析行为，因为DNS配置问题可能导致实际访问的地址与预期不符。