告别解析失败：在K8s集群内实现Service间无缝调用的Nginx与CoreDNS实战

1. 为什么你的K8s服务名解析总是失败？

第一次在K8s集群里用服务名调用其他服务时，看到Nginx报错"no resolver defined to resolve xxx"，我整个人都是懵的。明明在本地开发环境跑得好好的，怎么上了K8s就出问题？后来才发现，这是K8s网络通信中最常见的坑之一。

核心问题在于：当你在Nginx配置里用service-b.namespace这样的域名做代理转发时，Nginx默认不知道去哪里解析这个域名。这就像你让快递员送货，却不告诉他收件人住在哪个小区。在传统环境里，我们习惯用/etc/hosts或者公共DNS，但在K8s里这套行不通。

我遇到过最典型的场景是：前端服务用Nginx反向代理后端API，配置写的是proxy_pass http://backend-service.default:8080，结果Nginx直接抛解析错误。这时候你需要明白三件事：

1. K8s的Service域名体系是<service>.<namespace>.svc.cluster.local的格式
2. 默认的CoreDNS服务IP可以通过kubectl get svc -n kube-system查到
3. Nginx必须显式配置resolver才能识别这些内部域名

2. 五分钟搞定Nginx的DNS解析配置

先来看最直接的解决方案——修改Nginx配置。下面这个配置片段是我在线上环境验证过的：

nginx复制http {
    resolver 10.96.0.10 valid=1s ipv6=off;

    server {
        location /api {
            set $backend "backend-service.default.svc.cluster.local";
            proxy_pass http://$backend:8080;
        }
    }
}

关键点解析：

• resolver 10.96.0.10：这里的IP要换成你集群CoreDNS的ClusterIP，通过kubectl get svc -n kube-system | grep dns获取
• `valid=1