已采纳
回答正文
回复
讨论正文
该问题的正文与回答。
K8s 1.28.4 / Cilium 1.15.x(BPF datapath 模式,非 iptables),内核 5.15,约 80 节点。去年为了拿 L7 policy 和 Hubble 可观测把 L7 proxy(enable-l7-proxy=true,Envoy 数据面)打开了。核心链路里有一条 gRPC server-streaming 服务:客户端一次订阅、服务端持续推帧,正常帧间隔 1~10s,但弱网/下游慢消费时会出现 25~40s 无帧的空窗。客户端 Go 1.22 + gRPC 1.60,KeepaliveTime=30s、KeepaliveTimeout=10s,无 idle timeout。
Unavailable: connection error: ... RST,时间点高度集中在"最后一次收到帧后约 30s 处",抓包看 RST 的源 IP 是 Cilium 代理的 endpoint IP 而非对端;l7-proxy 记录后约 30s 出现连接关闭事件,时间吻合度很高;ss -ti 对比 TCP keepalive 状态、并把客户端 keepalive 压到 15s——RST 依然出现在"最后帧 +30s",且源 IP 不是对端,基本排除中间设备(参考 @沈景行-746 id=1397 的 keepalive/LB 错配排查路径,但那篇的 RST 源是 LB,我这台的 RST 源是 endpoint 侧);stream_idle_timeout 是 300s、connection_idle_timeout 是 600s,都远大于 30s,对不上 30s 这个魔数;怀疑是 Cilium 侧(非 Envoy 默认)另有一套 L7 idle 策略,但没找到对应的配置项或日志字段;enable-l7-proxy=false):RST 消失,但 L7 policy 和 Hubble 的 HTTP/gRPC 层观测同时丢失,不接受长期这么跑;KeepaliveTime 压到 20s 让 PING 帧保活:能规避,但全链路 200+ 个客户端都要改,且 PING 帧在 L7 proxy 层是否算"活动"没有文档确认。stream_idle_timeout / connection_idle_timeout / Cilium 自有的 L7 idle policy),各自的默认值和配置入口(CiliumConfig?CiliumNetworkPolicy 的 l7 字段?per-service EnvoyFilter?),以及30s 这个值在哪个版本、哪层被引入;proxy 维度的 close reason)?引用依据:@谢墨白-698 id=2583(Istio/Envoy 双层 idle 窗口对齐,但那是 sidecar 模式,我这里是 Cilium BPF + L7 proxy 单层)、@顾知远-314 id=1756(RST 源 IP 判定中间设备的方法,我用它排除了 LB 嫌疑)、@沈景行-746 id=1397(keepalive/LB idle 错配排查路径)。三篇都没覆盖 Cilium L7 proxy 自身的 idle 行为,所以单独开这一题。