gRPC 服务经 HAProxy L4 转发后偶发 502：TCP keepalive 与 LB idle timeout 到底怎么对齐才能根治？

【背景】 我在 K8s（1.28 / Calico CNI）里跑一批 Java gRPC 微服务，客户端 → HAProxy（stream 模式，L4 TCP 透传）→ 后端 Pod。后端 Pod 单实例并发连接 500~1500，连接是长连接复用（HTTP/2 over TCP），正常 P99 < 80ms。HAProxy 版本 2.8，配置里 timeout client 300s、timeout server 300s、timeout tunnel 3600s。

【现象】 大约每 2~4 小时出现一次"批次性"502：

• 同一后端 Pod 上的 20~80 条连接在 1~3s 内同时断开，客户端收到 RST 或 EOF；
• 后端进程日志里对应时间点有 "connection reset by peer"，但 handler 本身没 panic、没 OOM；
• HAProxy stats socket 里这些连接的 session 状态显示为 ST（timeout），duration ≈ 300s（刚好等于 timeout client/server）；
• 关键特征：断掉的连接都是"空闲超过 ~280s"的——即没有新 RPC 请求打上去的长连接。活跃连接不受影响。

【已尝试的排查】

1. 客户端 gRPC channel 默认没有开 TCP keepalive（grpc.keepalive_time 未设置），即纯靠 OS 层 keepalive（Linux 默认 tcp_keepalive_time=7200s，远大于 LB 的 300s）；
2. 后端 Java 进程里 SO_KEEPALIVE 是 true，但 tcp_keepalive_intvl=75s、tcp_keepalive_probes=9，意味着第一条 keepalive 探测要到 7200s 才发出——远晚于 LB 的 300s 超时；
3. 把 HAProxy 的 timeout client/server 临时调到 600s，502 频率降了一半但没有消失（变成了 ~600s 空闲时断）；
4. 抓包（tcpdump -i any port 50051）确认：HAProxy 侧先发出 FIN，100ms 后客户端回 RST（因为 HAProxy 已经 close 了 socket，客户端的 in-flight 请求直接收到 RST）；
5. 后端 netstat 里这些连接在断之前状态是 ESTABLISHED，没有 TIME_WAIT 堆积。

【卡点】 我理解根因是：OS 层 TCP keepalive 间隔（7200s）≫ LB idle timeout（300s），导致连接在 LB 看来"死了"被回收，但两端 OS 还认为连接活着。但具体怎么修、修到哪一层，我拿不准：

【期望得到的答案形态】

1. 对齐策略：gRPC 的 keepalive_time / keepalive_timeout / keepalive_permit_without_calls 三个参数应该设成什么值，才能确保在 HAProxy 300s timeout 之前发出心跳？是设 keepalive_time=60s 还是更激进？有没有"太频繁心跳反而被 LB 当异常流量"的风险？
2. HAProxy 侧：除了调大 timeout，有没有更优雅的配置（比如 tcp-check 主动探测、或 per-frontend 的 timeout 策略）？tunnel mode 和 non-tunnel mode 在 gRPC（HTTP/2）场景下该怎么选？
3. OS 层兜底：tcp_keepalive_time / intvl / probes 三个内核参数在 K8s Pod 里怎么生效（sysctl 还是 setsockopt）？改了之后对 1500 条连接有没有额外开销？
4. 可观测性：怎么在 Grafana 里加一个"连接空闲时长 vs LB timeout"的预警指标，在 502 发生前 5 分钟就告警？需要哪些数据源（HAProxy stats socket / netstat / eBPF）？
5. 欢迎贴 HAProxy 配置片段、gRPC channel 代码、sysctl 参数或监控面板配置，越可复现越好。