Istio环境下TCP客户端无法连接服务端故障咨询

核心故障可能点 #

• Go客户端应用启动时机早于Istio Sidecar就绪：Envoy代理注入后，Pod默认先启动业务容器再启动Sidecar容器，若你的Go TCP客户端在启动时就立即发起服务端连接，此时Sidecar尚未完成初始化，流量无法被正常拦截转发就会失败。而你后续手动执行nc命令时Sidecar已经完全就绪，因此可以正常连通。
• Kubernetes Service端口协议标识配置错误：Istio依赖Service的name字段前缀识别端口协议，TCP服务的端口名称必须配置为tcp-<自定义名称>格式，若未配置、字段为空或误用http/grpc等其他协议前缀，Istio会错误解析流量类型，导致经过Service的访问失败。你手动执行nc时直接访问PodIP，绕过了Service层的协议识别逻辑，因此可以连通。
• Sidecar出站访问规则限制：如果集群内配置了自定义Sidecar资源限制了客户端所在命名空间的出站访问范围，且你的TCP服务域名/ClusterIP不在允许的出站列表内，会导致客户端通过Service访问时被拦截。直接访问PodIP默认属于Istio的允许出站范围，因此不受影响。
• TCP长连接配置与Envoy规则冲突：若你的Go客户端使用了长连接复用逻辑，Envoy默认的TCP空闲连接超时时间为1小时，若客户端侧的空闲超时配置大于该值，会出现连接已被Envoy断开但客户端仍认为连接存活的异常，新建连接的nc命令不受该问题影响。

排查方案 #

• 检查服务端Service配置，确认端口name字段符合tcp-<自定义名称>的命名规范
• 给客户端Pod添加holdApplicationUntilProxyStarts: true配置，强制业务容器在Sidecar完全就绪后再启动，避免提前发起连接
• 检查集群内Sidecar、AuthorizationPolicy等权限控制资源，确认未限制客户端对服务端端口的访问权限
• 执行kubectl logs <客户端Pod名称> -c istio-proxy查看代理日志，根据连接错误码定位具体拦截原因

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