Guangyao Weng

空闲一段时间后尤其容易出现这种情况，telent本地端口又是正常的

> 这种情况正常应该会触发自动重连，如果不是持续发生的话，可能只是网络抖动原因 基本上只要空闲一段时间就会出现，kt-connect使用的ssh proxy似乎没有ServerAliveInterval的类似配置，有没有可能是这个问题呢？

> > 这种情况正常应该会触发自动重连，如果不是持续发生的话，可能只是网络抖动原因 > > 基本上只要空闲一段时间就会出现，kt-connect使用的ssh proxy似乎没有ServerAliveInterval的类似配置，有没有可能是这个问题呢？ 补充一下现场描述，一段时间空闲以后，每发送一个请求都会触发一次broken pipe，一定次数后就恢复正常。看起来的表象就像是长链接keep alive有些问题，但是双端都感知不到这个连接异常了，直到下次发送数据，然后断开重连。这里的一定次数看起来就像是ssh client和ssh server之间建立的长链接的数量？

> 正常情况下应该总是会添加所有Service和Pod的路由规则的，和选择哪一种DNS Mode无关。 > > 可以提供一下 --debug 参数的日志，观察一下日志中添加的路由IP段是否覆盖了所需的Pod和Service的IP地址。 > > 如果确实没有覆盖，在查明原因之前，可以先通过 `ktctl config set connect.include-ips=` 命令设置默认包含的额外IP段地址，可以免去每次执行connect命令时使用`--includeIps`参数。 背景是这样的，首先我设置了namespace的参数，想要在本地去访问跨命名空间的服务，这时候观察到ShadowPod会去解析跨命名空间服务的DNS，我观察到这里会做多次的dnslookup，不同的type，但是当type=1(A)的时候DNS查询有结果，type=28（AAA）的时候DNS查询结果为空(Empty answer for domain lookup)。 `[90m8:39PM DBG Found domain themis.xxxxxx. (1) in dns (127.0.0.1:38204)...

另外注意到ShadowPod会配置一个AUDIT_WRITE，集群有特殊的限制不允许这个Capability，注释掉以后能够正常工作，这个配置是否是必须的呢？