K8s中跨应用运行时动态获取服务主机与端口方案咨询

嘿，这个问题刚好是Kubernetes服务发现的核心场景之一，完全不用硬编码主机和端口，咱们用K8s内置的机制就能完美解决！

核心原理：Kubernetes内置DNS服务发现 #

Kubernetes集群默认会部署CoreDNS（或老版本的kube-dns），它会给每个Service自动分配一个可解析的域名。只要AppB被正确暴露为Service，AppA就能通过Service的名字直接访问，完全不需要硬编码IP或端口。

具体实现步骤 #

1. 为AppB创建ClusterIP类型的Service #

首先，你需要给AppB部署一个type: ClusterIP的Service（这也是Service的默认类型），用来在集群内部暴露AppB的REST API。示例YAML如下：

apiVersion: v1
kind: Service
metadata:
  name: app-b-service  # 这个名字就是AppA要用到的服务名
  namespace: default   # 如果和AppA在同一个命名空间，这里可以省略或保持一致
spec:
  selector:
    app: app-b         # 必须匹配AppB Pod的标签（比如你的AppB Pod的metadata.labels.app=app-b）
  ports:
    - protocol: TCP
      port: 80         # Service对外暴露的端口（AppA访问时用这个）
      targetPort: 8080 # AppB Pod实际监听的端口

注意：type: LoadBalancer是用来给外部用户访问应用的，内部服务间访问完全没必要用它，ClusterIP足够，而且更安全、更灵活。

2. AppA中动态访问的方式 #

根据AppA和AppB是否在同一个命名空间，访问地址略有不同：

• 同命名空间场景：直接用Service名称作为主机名，比如AppA的请求地址可以写成：

  http://app-b-service/api/app/getconfig
  

  K8s的DNS会自动把app-b-service解析为对应的Service ClusterIP，完全不用管具体的IP和端口。

• 不同命名空间场景：需要加上命名空间的后缀，格式为服务名.命名空间名.svc.cluster.local，比如AppB在backend命名空间，那么地址是：

  http://app-b-service.backend.svc.cluster.local/api/app/getconfig
  

  其中svc.cluster.local是K8s集群的默认域名后缀，大部分情况下可以省略，但加上会更明确。

3. 备选方案：利用K8s注入的环境变量 #

除了DNS方式，K8s还会自动给每个Pod注入所在命名空间下所有Service的环境变量。比如AppB的Service创建后，AppA的Pod里会自动生成以下环境变量：

• APP_B_SERVICE_HOST：对应Service的ClusterIP
• APP_B_SERVICE_PORT：对应Service暴露的端口

你也可以在AppA代码里读取这些环境变量来拼接请求地址，比如：

# 举个Python示例
import os
import requests

host = os.getenv("APP_B_SERVICE_HOST")
port = os.getenv("APP_B_SERVICE_PORT")
url = f"http://{host}:{port}/api/app/getconfig"
response = requests.get(url)

不过这种方式的缺点是：如果Service的名字或端口修改了，AppA的Pod需要重启才能获取新的环境变量，而DNS方式是实时生效的，所以更推荐DNS方式。

关键注意事项 #

• 确保AppB的Pod标签和Service的selector完全匹配，否则Service找不到Pod，AppA会访问失败。
• 检查CoreDNS组件是否正常运行（可以用kubectl get pods -n kube-system查看），DNS是服务发现的核心。
• 如果AppA有自己的DNS缓存，注意缓存时间不要太长，避免Service IP变更后无法及时解析。

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