这个场景在微服务依赖里挺常见的，我整理了3种基于Helm的可行方案，覆盖不同的部署场景，你可以根据自己的需求选：

方法1：Helm模板结合lookup函数（适合S1已预先部署的场景） #

如果S1是在S2之前部署的（或者属于同一个Chart但你能接受先部署S1再升级S2），可以用Helm的lookup函数在渲染S2的模板时直接查询S1 Service的外部IP。

在S2的Deployment模板里，给容器添加环境变量：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-s2
spec:
  # ... 其他配置（ replicas、selector等） ...
  template:
    spec:
      containers:
        - name: s2
          # ... 镜像、端口等基础配置 ...
          env:
            - name: S1_EXTERNAL_IP
              # 用lookup查询S1 Service的外部IP，默认值为空字符串防止渲染失败
              value: {{ (lookup "v1" "Service" .Release.Namespace (printf "%s-s1" .Release.Name)).status.loadBalancer.ingress[0].ip | default "" }}

注意事项：

• 第一次同时部署S1和S2时，S1的LoadBalancer IP还没被云厂商分配，lookup会返回空值，这种情况需要后续执行helm upgrade来更新S2的环境变量。
• 如果你的集群里S1的名字或者命名空间有变化，要对应调整lookup里的参数。

方法2：Init Container + Kubernetes API查询（通用运行时方案） #

这是最通用的方案，不管S1和S2是否同时部署，都能在S2 Pod启动前主动获取S1的外部IP，还能处理IP未就绪的等待逻辑。

步骤1：给S2的Pod分配权限读取S1 Service #

首先在Helm Chart里创建ServiceAccount、Role和RoleBinding，让S2的Pod能合法查询S1的状态：

# templates/s2-serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: {{ .Release.Name }}-s2-sa
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: {{ .Release.Name }}-s1-reader
rules:
  - apiGroups: [""]
    resources: ["services"]
    verbs: ["get"]
    resourceNames: ["{{ .Release.Name }}-s1"] # 仅允许读取S1这个特定Service
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: {{ .Release.Name }}-s2-sa-binding
subjects:
  - kind: ServiceAccount
    name: {{ .Release.Name }}-s2-sa
    namespace: {{ .Release.Namespace }}
roleRef:
  kind: Role
  name: {{ .Release.Name }}-s1-reader
  apiGroup: rbac.authorization.k8s.io

步骤2：在S2的Deployment里添加Init Container #

用轻量的kubectl镜像，在S2主容器启动前循环查询S1的外部IP，直到获取到后写入共享卷，让主容器读取：

# templates/s2-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-s2
spec:
  replicas: {{ .Values.s2.replicas }}
  selector:
    matchLabels:
      app: s2
  template:
    metadata:
      labels:
        app: s2
    spec:
      serviceAccountName: {{ .Release.Name }}-s2-sa # 绑定刚才创建的ServiceAccount
      initContainers:
        - name: fetch-s1-ip
          image: bitnami/kubectl:latest # 选用轻量镜像减少资源占用
          command:
            - sh
            - -c
            - |
              # 循环等待S1的外部IP被云厂商分配
              until S1_IP=$(kubectl get service {{ .Release.Name }}-s1 -o jsonpath='{.status.loadBalancer.ingress[0].ip}'); do
                echo "Waiting for S1 external IP to be available..."
                sleep 5
              done
              # 将IP写入共享卷的文件，供主容器读取
              echo "$S1_IP" > /shared/s1-ip.txt
          volumeMounts:
            - name: s1-ip-volume
              mountPath: /shared
      containers:
        - name: s2
          image: {{ .Values.s2.image.repository }}:{{ .Values.s2.image.tag }}
          # 方式：从共享卷读取IP文件（需要你的应用支持读取文件获取配置）
          volumeMounts:
            - name: s1-ip-volume
              mountPath: /etc/s1-config
              readOnly: true
      volumes:
        - name: s1-ip-volume
          emptyDir: {} # 临时共享卷，Pod重启后会重置

注意事项：

• 如果S1的外部IP可能在运行时变化（比如云厂商重新分配），这个方案只能在Pod启动时获取一次，后续变化不会自动更新。如果需要动态感知，可以把Init Container改成Sidecar容器，定期更新文件并让应用支持热加载配置。

方法3：利用ExternalName Service（仅适合S1有固定外部域名的场景） #

如果你的S1 LoadBalancer有固定的外部域名（比如云厂商提供的LoadBalancer专属域名，而非动态IP），可以用Kubernetes的ExternalName Service来间接引用，这样S2只需要访问这个Service的域名即可，不需要关心底层IP。

不过这个方案只适合S1有固定域名的情况，动态IP场景不适用：

# templates/s1-externalname.yaml
apiVersion: v1
kind: Service
metadata:
  name: {{ .Release.Name }}-s1-external
spec:
  type: ExternalName
  externalName: your-s1-loadbalancer-domain.example.com # 替换成S1的实际外部域名

之后S2的应用里直接访问{{ .Release.Name }}-s1-external这个域名即可，Kubernetes会自动解析到S1的外部IP。

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