K8s集群内无法通过服务名作为URL实现服务间通信的问题

核心问题：API B未创建Service是解析失败的直接原因 #

Kubernetes中，只有Service资源会在集群DNS中生成稳定的域名记录（格式为<service-name>.<namespace>.svc.cluster.local），Deployment本身不会提供DNS解析入口。你提到的api-b.default.svc.cluster.local这个域名，只有当存在名为api-b的Service时才会被DNS解析到对应的Pod。Docker Compose里的"服务名"对应Kubernetes的Service，而非Deployment，这是两者的核心差异。

Pod命名对解析无影响 #

Pod名称末尾的哈希值是Deployment控制器为区分不同版本ReplicaSet生成的，和集群DNS解析逻辑无关，不会导致域名无法识别的问题。

其他排查方向 #

• 确认API B的Pod状态：执行kubectl get pods -l app=api-b（替换app=api-b为你Deployment定义的Pod标签），检查Pod是否处于Running状态且就绪（READY列显示1/1）。
• 测试集群DNS基础功能：在API A的Pod内执行nslookup kubernetes.default，如果无法解析，说明集群DNS组件（如CoreDNS）异常，需检查kube-system命名空间下的CoreDNS Pod状态。
• 直接用Pod IP测试连通性：通过kubectl get pods <api-b-pod-name> -o wide获取Pod的IP地址，在API A中尝试访问http://<pod-ip>:8080。如果能通，说明网络连通性正常，问题确实出在Service/DNS；如果不通，需检查：
  • Deployment中容器的containerPort是否配置为8080
  • 是否存在网络策略（NetworkPolicy）阻止了API A到API B的访问
• 确认命名空间一致性：检查API A和API B是否部署在同一个命名空间（默认是default）。若API B在其他命名空间，即使创建Service，访问地址也需改为api-b.<namespace>.svc.cluster.local。
• 检查Kompose生成的清单：执行kubectl get services，确认是否Kompose自动生成了API B的Service但被误删。Kompose默认会为Docker Compose中的每个服务生成ClusterIP类型的Service。

解决方案：为API B创建ClusterIP Service #

因为API B仅需内部访问，创建ClusterIP类型的Service即可（默认类型就是ClusterIP）。示例清单如下：

apiVersion: v1
kind: Service
metadata:
  name: api-b
  namespace: default
spec:
  selector:
    app: api-b  # 必须与API B Deployment中定义的Pod标签完全匹配
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080  # 需与API B容器暴露的端口一致

创建后，API A即可通过http://api-b:8080或http://api-b.default.svc.cluster.local:8080正常访问API B。

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