启用Istio注入后Kubernetes上PostgreSQL HA集群节点连接失败求助

看起来你遇到的核心问题是：启用Istio Sidecar注入后，PostgreSQL StatefulSet的第二个Pod无法通过Headless Service连接到第一个Pod，而未注入时集群运行完全正常。结合你提供的日志和环境信息，我来梳理可能的故障原因和解决办法：

先理解关键日志含义 #

你的Istio-proxy日志里出现了response_flags": "UF,URX"，这两个标记的意思是：

• UF：Upstream Failure，上游服务连接失败
• URX：Upstream Reset by Peer，上游端重置了连接

这说明Istio Sidecar在转发PostgreSQL Pod间的流量时，遇到了连接层面的阻断，大概率是Istio的流量策略或Sidecar配置与PostgreSQL的通信需求不匹配导致的。

具体排查与解决步骤 #

1. 检查Istio对Headless Service的流量处理 #

Headless Service没有ClusterIP，Istio默认对这类服务的流量转发逻辑和普通Service不同。你需要明确为PostgreSQL的Headless Service配置流量规则：
创建一个DestinationRule，指定TCP协议（PostgreSQL用TCP通信）和端口配置：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: postgresql-ha-dr
  namespace: gitlab-test
spec:
  host: postgreslq-test-postgresql-ha-postgresql-headless.gitlab-test.svc.cluster.local
  subsets:
  - name: postgresql
    trafficPolicy:
      loadBalancer:
        simple: ROUND_ROBIN
      portLevelSettings:
      - port:
          number: 5432
        tcp:
          connectTimeout: 10s

2. 检查mTLS配置冲突 #

如果你的命名空间开启了全局严格模式的mTLS，PostgreSQL Pod之间的通信可能因为没有适配Istio的mTLS认证而被阻断。可以为PostgreSQL服务单独配置宽松模式的PeerAuthentication：

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: postgresql-ha-pa
  namespace: gitlab-test
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: postgresql-ha
  mtls:
    mode: PERMISSIVE

PERMISSIVE模式允许明文和mTLS流量同时存在，适配PostgreSQL自身的认证机制。

3. 调整Sidecar的出站流量规则 #

Istio Sidecar默认会拦截所有出站流量，但可能没有明确允许PostgreSQL的5432端口。可以创建Sidecar资源，明确授权该端口的出站访问：

apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: postgresql-ha-sidecar
  namespace: gitlab-test
spec:
  workloadSelector:
    labels:
      app.kubernetes.io/name: postgresql-ha
  egress:
  - hosts:
    - "postgreslq-test-postgresql-ha-postgresql-headless.gitlab-test.svc.cluster.local"
    ports:
    - number: 5432
      protocol: TCP
      name: tcp-postgresql

4. 验证PostgreSQL的访问控制列表（pg_hba.conf） #

Istio注入后，Pod的出站流量会经过Sidecar转发，源IP会变成Sidecar的IP而非Pod本身的IP。你需要检查第一个Pod的pg_hba.conf，是否允许Sidecar所在IP段的访问：
比如添加类似规则（根据你的集群CIDR调整）：

host all all 10.93.0.0/16 md5

5. 验证Sidecar端点配置 #

执行以下命令，检查第二个Pod的Istio Sidecar是否能识别到第一个Pod的端点：

kubectl exec -it postgreslq-test-postgresql-ha-postgresql-1 -c istio-proxy -- istioctl proxy-config endpoints

如果能看到第一个Pod的10.93.202.188:5432端点，说明服务发现正常，问题大概率在流量策略或认证层面。

总结 #

优先从Istio的流量策略（DestinationRule、PeerAuthentication）入手调整，因为未注入Istio时集群正常，说明PostgreSQL本身的配置是没问题的。Istio注入后改变了流量转发路径，需要明确适配PostgreSQL的TCP通信需求，同时注意源IP变化带来的pg_hba.conf访问限制问题。

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