OpenStack执行server list命令偶发无法连接nova-api端点报错如何解决

该报错核心错误码为Errno -2 Name or service not known，说明执行openstack server list命令的节点无法解析nova-api-proxy.openstack.svc.cluster.local这个Kubernetes内部服务域名，偶发、可自动恢复的特性对应以下几种常见原因：

• Kubernetes CoreDNS服务抖动：CoreDNS副本数不足、负载过高、Pod滚动重启/节点漂移期间，DNS请求无法得到正常响应，CoreDNS恢复后解析自动正常。
• 节点DNS配置不合理：节点/etc/resolv.conf未配置足够的DNS重试次数、超时时间过短，单次UDP DNS请求丢包就直接返回解析失败。
• 本地DNS缓存异常：节点上部署的nscd、dnsmasq等本地DNS缓存服务偶发故障、缓存过期未及时刷新，导致短时间内解析失败。
• 集群网络抖动：执行命令的节点和CoreDNS服务之间网络偶发丢包，UDP协议的DNS请求默认无重试机制，直接触发解析错误。

• 先确认域名解析是否是故障点：在报错的节点上反复执行nslookup nova-api-proxy.openstack.svc.cluster.local，如果也出现偶发解析失败，即可确定是DNS链路的问题。
• 检查CoreDNS运行状态：在Kubernetes控制节点执行kubectl get pods -n kube-system -l k8s-app=kube-dns，确认CoreDNS副本数是否充足，有没有频繁重启的情况；查看CoreDNS日志kubectl logs -n kube-system <coredns-pod-name>，确认是否存在请求超时、解析报错的记录。
• 检查节点DNS配置：查看报错节点的/etc/resolv.conf文件，确认首条nameserver是否指向集群内部DNS，是否存在多余的外部DNS配置导致解析请求偶尔走外网失败；检查options配置是否包含足够的重试、超时参数。
• 检查本地DNS缓存服务状态：如果节点运行了nscd/dnsmasq服务，执行systemctl status nscd或systemctl status dnsmasq确认服务是否正常，有没有频繁重启的记录。
• 排查网络质量：用mtr <coredns-pod-ip>命令测试报错节点到CoreDNS Pod的网络丢包率，确认是否存在偶发UDP 53端口丢包的情况。

• CoreDNS性能不足：根据集群规模扩容CoreDNS副本到2~4个，开启CoreDNS缓存插件延长域名缓存时间，降低CoreDNS负载。
• 节点DNS配置优化：修改/etc/resolv.conf，只保留集群内部DNS作为首选项，添加重试和超时配置：options timeout:2 attempts:3 ndots:5，避免单次请求失败直接返回错误。
• 本地缓存异常：重启nscd/dnsmasq服务，调整缓存TTL到合理值，也可以直接禁用不必要的本地DNS缓存服务，直接走集群DNS解析。
• 网络丢包优化：将CoreDNS Pod调度到负载较低的节点，开启DNS TCP fallback机制，避免UDP丢包影响解析结果。
• 临时规避方案：将nova-api-proxy.openstack.svc.cluster.local和对应的Service ClusterIP写入报错节点的/etc/hosts文件，硬编码解析规则，彻底避免DNS解析抖动的影响。

内容的提问来源于stack exchange，提问作者qihang