Kubernetes中auth与frontend服务的内部连接配置求助

咱们一步步来排查并解决服务间内部调用的问题：

1. 先确认服务与Pod的关联是否正常 #

首先检查auth服务是否正确绑定到了对应的Pod：

kubectl describe service auth

在输出的Endpoints部分，应该能看到auth Pod的IP和8000端口（比如10.XX.XX.XX:8000）。如果这里是空值，才需要检查selector和Pod标签的匹配度，但看你的配置，auth服务的selectorapp: auth, tier: backend和Pod的标签完全对应，这一步大概率没问题，但确认下更稳妥。

2. 进入FE容器直接测试网络连通性 #

这是最直接的排查方式，先进入FE的Pod内部：

# 先获取FE的Pod名称
kubectl get pods -l app=fe
# nginx镜像用sh进入，其他镜像可以用bash
kubectl exec -it <fe-pod-name> -- /bin/sh

进入容器后分两步测试：

• 测试DNS解析：

  nslookup auth
  

  如果能解析到auth服务的ClusterIP，说明集群DNS正常；如果解析失败，可能是coredns组件异常，或者Pod的DNS配置有问题。
• 测试HTTP调用：

  curl http://auth:3000
  

  如果返回服务正常响应，说明内部连通没问题，问题出在FE应用的代码配置上；如果返回连接超时/拒绝，继续往下排查。

3. 确认Auth服务的容器端口是否正常监听 #

进入auth的Pod，检查8000端口是否在正常监听：

kubectl exec -it <auth-pod-name> -- /bin/bash
# 用netstat或ss检查端口状态
netstat -tulpn | grep 8000
# 或者
ss -tulpn | grep 8000

如果看不到8000端口的监听记录，说明auth应用没有正确启动，或者配置成了监听其他端口，这时候查看Pod日志定位问题：

kubectl logs <auth-pod-name>

根据日志调整应用的监听端口，或者修改Deployment的containerPort和Service的targetPort。

4. 检查是否有网络策略限制 #

如果你的集群启用了网络策略，可能存在阻止FE与Auth通信的规则，检查当前命名空间的网络策略：

kubectl get networkpolicies

如果存在策略，确认是否允许带有app: fe, tier: frontend标签的Pod访问auth服务的3000端口。

5. 跨命名空间场景（如果适用） #

如果两个服务不在同一个命名空间（默认都是default，没修改的话忽略），需要使用完整的服务域名调用：

http://auth.<namespace>.svc.cluster.local:3000

比如auth在backend命名空间，FE在frontend命名空间，就用http://auth.backend.svc.cluster.local:3000。

常见修复场景总结 #

• FE应用代码里的调用地址写错：修正为http://auth:3000（跨命名空间则用完整域名）
• Auth容器未监听8000端口：调整应用配置，或同步修改Deployment的containerPort和Service的targetPort
• DNS解析失败：重启coredns组件：kubectl rollout restart deployment coredns -n kube-system

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