Istio Idle Timeout问题复现和解决
March 25, 2024
更新 2024-04-01 #
通过调整 tcp_proxy 的 idle_timeout 参数后，部分中间件（redis, mongo）的异常问题不再出现，但是 mysql(sharding-spere) 和 memcached 仍然存在 “invalid connection” 错误，所以还需要找到能够解决 mysql(sharding-spere) 和 memcached 的方法。
上述描述的现象非常主观，不一定正确也不能作为最终结论，但是 idle_timeout 配置确实没有解决所有的问题。
这里，需要知道 istio 在 inject 时会通过 iptables 对应用的流量进行劫持，对于 outbound 的流量 iptables 规则拦截转发到 OUTPUT 链。OUTPUT 的链转发流量到 ISTIO_OUTPUT，这个链会决定服务访问外部服务的流量发往何处。
这样产生的效果是，除了应用自己建立的连接之外 envoy 也会创建一个代理连接。
$ netstat -notp | grep 3307
tcp 0 172.23.105.25:41030 x.x.x.x:3307 ESTABLISHED - off(0.00/0/0)
tcp 0 172.23.105.25:41022 x.x.x.x:3307 ESTABLISHED 1/./app keepalive(0.88/0/0)
我遇到的问题可以确定问题就出在 envoy 建立的连接上，因为应用自己建立的连接是正常的，同时还可以看到应用自己的连接开启了 keepalive, 而 envoy 建立的连接没有开启。这样可能会出现这个连接会因为超时而被关闭的情况，或者其他原因导致连接被释放。那如果可以避免将中间件的流量通过 envoy 代理，这样就可以避免这个问题。
在官方的文档中也提到，https://istio.io/latest/zh/docs/tasks/traffic-management/egress/egress-control/ 对于外部服务，可以通过配置 excludeOutboundPorts 或者 excludeOutboundIPRanges 来使得某些服务的流量不经过 istio sidecar。其背后的原理是通过 iptables 的规则中排除这些端口或者 IP 地址。