带有Istio Sidecar的Pod无法curl访问Elasticsearch问题排查

从你的场景来看，核心矛盾出在Istio Sidecar的流量拦截逻辑和无Sidecar的Elasticsearch集群不兼容上，下面是具体的原因拆解和解决步骤：

最可能的根因：Istio强制双向TLS（mTLS）导致握手失败 #

大概率是你的Istio集群开启了全局或proto命名空间级别的mTLS强制模式——当带Sidecar的Pod发起请求时，Istio代理会自动尝试用自身颁发的客户端证书，和目标服务建立mTLS连接。但Elasticsearch所在的logging命名空间没有部署Sidecar，也没有配置mTLS支持，两边的SSL协议逻辑完全不匹配，自然会抛出Unknown SSL protocol error。

快速排查验证步骤 #

• 先检查Istio的mTLS全局/命名空间配置：

  kubectl get peerauthentication.security.istio.io -A
  

  如果看到proto命名空间或全局的PeerAuthentication设置了mode: STRICT，那实锤是强制mTLS导致的问题。

• 再确认目标服务的流量规则：

  kubectl get destinationrule.networking.istio.io -n logging
  

  如果没有针对Elasticsearch服务的DestinationRule，或者配置的TLS模式和Elasticsearch实际SSL逻辑不匹配，也会触发这类错误。

针对性解决方法 #

方法1：给Elasticsearch配置跳过mTLS的规则 #

在proto命名空间（或全局istio-system）创建DestinationRule，明确告诉Sidecar访问Elasticsearch时禁用mTLS：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: elasticsearch-no-mtls
  namespace: proto
spec:
  host: elasticsearch-elasticsearch-cluster.logging.svc.cluster.local
  trafficPolicy:
    tls:
      mode: DISABLE

应用后，Sidecar就会用普通HTTPS请求访问Elasticsearch，不再强制发起mTLS握手。

方法2：调整mTLS的生效范围 #

如果全局开启了mTLS，可以把logging命名空间排除在强制规则外，或者将模式改为PERMISSIVE（兼容模式）：

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: PERMISSIVE # 允许mTLS和普通流量共存
  targetRefs:
  - kind: Namespace
    name: proto # 仅在proto命名空间生效

PERMISSIVE模式下，Sidecar会优先尝试mTLS，但如果目标服务不支持，会自动降级为普通TLS/HTTP请求。

方法3：适配Elasticsearch的自有SSL证书 #

如果Elasticsearch本身启用了自定义SSL，需要让Istio Sidecar能识别它的CA证书。先把Elasticsearch的CA证书存入K8s Secret：

kubectl create secret tls elasticsearch-ca-secret --cert=./es-ca.crt --key=./es-ca.key -n proto

再创建对应DestinationRule关联这个证书：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: elasticsearch-ssl
  namespace: proto
spec:
  host: elasticsearch-elasticsearch-cluster.logging.svc.cluster.local
  trafficPolicy:
    tls:
      mode: SIMPLE
      credentialName: elasticsearch-ca-secret

额外排查技巧 #

• 查看Sidecar的代理日志，获取更详细的SSL错误细节：

  kubectl logs <你的proto命名空间Pod名称> -c istio-proxy -n proto
  

  日志里通常会明确指出是证书不匹配、协议版本不兼容还是其他握手问题。

• 确认Elasticsearch的SSL配置本身正常：比如9200端口确实启用了HTTPS、证书未过期、服务地址解析正常。

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