Kubernetes集群内服务间通信配置问询

嘿，我来帮你梳理清楚Kubernetes集群内服务访问的这些问题，都是日常开发运维中高频遇到的场景，实用度拉满～

一、集群内访问服务的方式（无需走Ingress） #

Ingress是用来对外暴露集群服务的入口，集群内部访问服务有更直接、高效的方式，完全不需要绕Ingress主机：

• Service DNS域名访问（最推荐）
  K8s内置的CoreDNS会为每个Service自动生成可解析的域名，格式为：

  {{service-name}}.{{namespace-name}}.svc.cluster.local
  

  如果两个服务在同一个命名空间下，甚至可以简化为直接用{{service-name}}访问。比如你的Service B在default命名空间，集群内的Pod或其他服务直接用service-b就能访问到它，无需额外配置。

• ClusterIP直接访问
  每个Service默认会分配一个固定的ClusterIP（除非是Headless Service），你可以通过kubectl get svc查看这个IP，然后用http://<cluster-ip>:<service-port>访问。不过这种方式不推荐，因为ClusterIP在Service重建时可能会变化，不如DNS域名稳定。

• Headless Service访问（特殊场景）
  如果需要直接访问后端Pod而非通过Service的负载均衡，可以创建Headless Service（设置spec.clusterIP: None），此时CoreDNS会返回该Service关联的所有Pod的IP地址，适合数据库集群、状态化应用等场景。

二、是否需要采用Ingress主机方式访问集群内服务？ #

完全不需要！虽然理论上如果集群内Pod能解析Ingress的公网主机名（比如你的Ingress域名被解析到Ingress Controller的ClusterIP），也能通过Ingress地址访问，但这属于绕远路：

• 多了一层Ingress Controller的转发，增加延迟和故障点
• 不符合K8s集群内服务通信的最佳实践
• 当Ingress配置变更（比如路径、TLS）时，还可能影响内部访问

所以集群内访问坚决用Service的DNS域名或ClusterIP，别碰Ingress。

三、Service A配置文件中如何与Service B通信？ #

核心就是在Service A的配置里写入Service B的DNS访问地址，具体分两种常见场景：

1. 直接在应用配置中写死（简单场景） #

如果Service B的名称和命名空间固定，直接在Service A的应用配置文件里写访问地址即可。比如：

• 同命名空间：http://service-b:8080/api（假设Service B的端口是8080，接口路径是/api）
• 不同命名空间：http://service-b.backend.svc.cluster.local:8080/api（Service B在backend命名空间）

2. 通过配置中心/环境变量注入（推荐，更灵活） #

为了避免硬编码，通常会用ConfigMap或Secret来存储Service B的访问地址，然后注入到Service A的Pod环境变量中，让应用读取环境变量来发起请求。

举个ConfigMap的例子：

apiVersion: v1
kind: ConfigMap
metadata:
  name: service-a-config
  namespace: default
data:
  SERVICE_B_ENDPOINT: "http://service-b.backend.svc.cluster.local:8080"

然后在Service A的Deployment中挂载这个ConfigMap为环境变量：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: service-a
spec:
  replicas: 2
  template:
    spec:
      containers:
      - name: service-a-app
        image: your-service-a-image:latest
        env:
        - name: SERVICE_B_URL
          valueFrom:
            configMapKeyRef:
              name: service-a-config
              key: SERVICE_B_ENDPOINT

这样Service A的应用只需要读取环境变量SERVICE_B_URL，就能和Service B通信，后续如果Service B的地址变更，只需要修改ConfigMap即可，不用重新打包镜像。

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