带Istio Sidecar的Kafka客户端无法连接Kafka集群的问题咨询

问题1：Istio-proxy连接Kafka与普通TCP连接行为为何不同？ #

这个问题的核心在于Istio对Kafka协议的自动识别和MTLS强制逻辑，和普通TCP流量（比如nc）的处理方式有本质区别：

• 当Kafka客户端发起连接时，Istio会通过初始的协议帧特征自动识别出这是Kafka流量。如果你的Istio环境有全局MTLS强制（或者针对Kafka服务的DestinationRule配置了STRICT模式），客户端侧的Istio-proxy会自动对这个连接启用TLS加密，试图发送TLS握手数据到Kafka的明文监听端口（比如9092）。
• 但你的Kafka集群是明文配置的，没有开启TLS，它会把收到的TLS握手字节直接当成Kafka协议的消息帧解析。Kafka的消息帧开头是4字节大端的消息长度，而TLS握手的前4字节（0x16 0x03 0x01 0x00）被解析成十进制的369295616，远超过Kafka默认的100MB消息大小限制，所以触发InvalidReceiveException，服务端直接重置连接，导致客户端报Connection reset by peer。
• 而nc这类普通TCP连接的情况：如果你只是用nc建立连接但不发送Kafka协议特征的数据流，Istio-proxy可能还没完成协议识别，不会强制启用MTLS封装；或者nc发送的是无特征的字节，Istio将其视为普通TCP流量，此时如果没有针对该服务的严格MTLS规则，就允许明文连接，所以能成功建立（至少不会触发Kafka的协议解析错误）。

问题2：如何仅对单个主机禁用MTLS？ #

你之前尝试PeerAuthentication没成功，是因为PeerAuthentication是控制服务端是否接受MTLS流量，而我们需要的是让客户端侧不对Kafka服务发起MTLS连接，所以需要结合DestinationRule和PeerAuthentication来配置：

步骤1：针对Kafka服务创建DestinationRule，强制客户端用明文连接

假设你的Kafka服务FQDN是kafka-cluster-kafka-bootstrap.kafka.svc.cluster.local（替换成你实际的服务名和命名空间），创建如下配置：

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: kafka-disable-mtls
  namespace: kafka # Kafka服务所在的命名空间
spec:
  host: kafka-cluster-kafka-bootstrap.kafka.svc.cluster.local
  trafficPolicy:
    tls:
      mode: DISABLE # 明确禁用对该服务的MTLS

如果客户端和Kafka在同一个命名空间，host也可以简化为kafka-cluster-kafka-bootstrap，但使用完整FQDN更稳妥。

步骤2：配置PeerAuthentication允许Kafka服务接受明文流量

如果你的Istio全局PeerAuthentication是STRICT模式（强制所有流量用MTLS），需要针对Kafka所在的命名空间创建宽松的PeerAuthentication，允许明文连接：

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: kafka-allow-plaintext
  namespace: kafka
spec:
  mtls:
    mode: PERMISSIVE # 允许明文和MTLS流量共存

步骤3：验证配置

重启注入了Istio-proxy的Kafka客户端Pod，让新的配置生效。之后查看客户端日志，如果不再出现Connection reset by peer，且能正常消费/生产消息，说明配置成功。

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