Minikube集群中Vanilla JS请求后端出现ERR_NAME_NOT_RESOLVED问题排查

嘿，我一眼就抓准了问题的核心——你的前端JavaScript代码是在用户的浏览器里运行的，而浏览器根本无法识别Kubernetes集群内部的be Service域名！

为什么Pod内的命令能成功，但浏览器不行？ #

• 当你在前端Pod里执行nslookup be或者curl be/be/test/hi时，这些请求是在K8S集群的内部网络环境中处理的：集群自带的CoreDNS服务会负责解析内部Service的域名，所以能正常返回结果。
• 但浏览器是运行在集群外部的（哪怕你用的是Minikube，浏览器也是宿主机上的进程），它使用的是宿主机的DNS服务器，这个服务器完全不知道K8S集群内部的be域名对应的IP地址，因此必然会抛出ERR_NAME_NOT_RESOLVED错误。

你的反向代理解决方案为什么有效？ #

你通过Apache配置反向代理的思路非常准确，相当于做了一层"中转"：

1. 你把JS里的请求URL改成了相对路径（去掉了http://be前缀），这样浏览器会将请求发送到当前页面所在的域名（也就是你的前端Service暴露的地址），避免了直接去解析陌生的be域名。
2. Apache的ProxyPass /be/ http://be/be/规则会把所有以/be/开头的请求，转发到K8S集群内部的be Service。这一步是在前端Pod内部完成的，属于集群内网请求，自然能被CoreDNS正常解析并获取后端响应。

其他可选的生产级解决方案 #

除了反向代理，还有几种更通用的方案适合生产环境：

• 使用Ingress统一路由：创建K8S Ingress资源，将同一个域名下的不同路径分别路由到前端和后端（比如/fe/*指向前端服务，/be/*指向后端服务）。这样浏览器只需要请求同一个域名，完全不需要关心集群内部的Service结构。
• 通过环境变量注入API路径：将后端API的相对路径（比如/be）通过K8S ConfigMap或Secret注入到前端容器，让前端JS使用相对路径发起请求，避免硬写集群内部域名。
• 测试环境用NodePort（不推荐生产）：如果只是临时测试，可以将后端Service改为NodePort类型，然后在前端JS里直接使用http://<MinikubeIP>:<NodePort>/be/test/hi作为请求地址。但这种方式IP和端口不稳定，不适合生产环境。

总结 #

核心要点是区分集群内部网络和外部客户端网络的差异：K8S内部的Service域名仅能在Pod或集群节点内解析，外部客户端（如浏览器）无法直接访问。反向代理和Ingress路由是生产环境中最可靠的解决方案。

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