根据你描述的情况，结合Istio服务网格和kube-prometheus-stack的特性，这个502错误的核心原因几乎都和Istio Sidecar对Prometheus采集流量的拦截与管控有关，具体拆解如下：

可能的成因 #

• Istio mTLS策略冲突：如果集群启用了严格模式的mTLS，monitoring命名空间的Prometheus与目标服务所在命名空间之间没有配置跨命名空间的mTLS信任关系，Istio会拦截请求并返回502。
• 流量端口协议识别错误：Helm自动生成的ServiceMonitor可能未明确指定metrics端口的协议（比如http），Istio若错误推断协议（比如当成TCP流量处理），会导致请求转发失败。
• Sidecar出站流量限制：目标服务Pod注入了Istio Sidecar，但Sidecar的出站规则未允许来自monitoring命名空间Prometheus的访问请求，或未正确路由到metrics端点。
• Headless Service的Istio处理异常：若异常目标对应Headless Service，Istio对这类服务的端点发现逻辑可能存在兼容问题，导致无法正确转发请求。

分步修复方法 #

1. 先排查Sidecar日志定位具体原因 #

先查看异常目标Pod的Istio Sidecar日志，精准定位502的触发点：

# 替换<target-pod>和<target-namespace>为实际值
kubectl logs <target-pod> -n <target-namespace> istio-proxy

如果日志出现peer certificate not trusted或mTLS handshake failed，说明是mTLS问题；如果是no route configured，则是路由或端口协议问题。

2. 解决mTLS信任问题 #

如果是mTLS导致的，配置目标命名空间与monitoring命名空间之间的信任策略：

• 创建PeerAuthentication资源，允许目标命名空间接受来自monitoring的mTLS请求（或放宽到PERMISSIVE模式，允许混合流量）：

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: <target-namespace>
spec:
  mtls:
    mode: PERMISSIVE

• 或者为monitoring命名空间的Prometheus配置DestinationRule，指定访问目标服务时使用mTLS：

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: target-service-mtls
  namespace: monitoring
spec:
  host: "<target-service>.<target-namespace>.svc.cluster.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

3. 修正ServiceMonitor的端口协议配置 #

Helm自动生成的ServiceMonitor可能缺失协议配置，修改Helm values补充：
在kube-prometheus-stack的values.yaml中，找到对应服务的ServiceMonitor配置（或全局设置），确保端点指定正确协议：

prometheus:
  prometheusSpec:
    serviceMonitorSelectorNilUsesHelmValues: false
    serviceMonitorNamespaceSelector: {}
serviceMonitors:
  # 以node-exporter为例，确保协议正确
  nodeExporter:
    enabled: true
    namespace: kube-system
    endpoints:
    - port: metrics
      scheme: http
      path: /metrics

同时确保目标Service的metrics端口有明确名称（比如name: metrics），Istio会根据端口名称自动识别HTTP协议。

4. 配置Istio允许Prometheus的采集流量 #

如果是Sidecar出站规则限制，为目标命名空间的Sidecar配置AuthorizationPolicy，允许来自monitoring命名空间的Prometheus访问metrics端口：

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-prometheus-scrape
  namespace: <target-namespace>
spec:
  selector:
    matchLabels:
      # 替换为目标服务的Pod标签
      app: <target-app>
  rules:
  - from:
    - source:
        namespaces: ["monitoring"]
    to:
    - operation:
        ports: ["<metrics-port>"]

5. 处理Headless Service的兼容问题 #

如果异常目标是Headless Service，在Istio中配置ServiceEntry正确识别端点：

apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: headless-target-service
  namespace: <target-namespace>
spec:
  hosts:
  - "<headless-service>.<target-namespace>.svc.cluster.local"
  ports:
  - number: <metrics-port>
    name: http-metrics
    protocol: HTTP
  resolution: STATIC
  endpoints:
  - address: <pod-ip-1>
  - address: <pod-ip-2>
  # 若Headless Service的DNS正常，也可使用DNS方式
  # resolution: DNS

验证修复 #

完成配置后，重启Prometheus Pod：

kubectl rollout restart statefulset prometheus-stack-kube-prom-prometheus -n monitoring

随后查看Prometheus Targets页面，确认异常目标是否恢复正常。

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