K8s 跨节点 TCP 层「网络金丝雀」怎么设计：探针间隔、包大小、阈值怎么定才能把 P99 毛刺提前 30s 抓住，而不是等应用侧 5xx 才回头看？

背景

15 年网络工程，目前保一个 K8s 1.26 集群（约 90 节点、Calico VXLAN iptables 模式、双口 25G、内核 5.10）。业务侧反复出现「P99 从 80ms 跳到 400~800ms，持续 5~20s 后自愈」的尖峰，但现有监控（Prometheus + node_exporter + SkyWalking）在尖峰期间只能看到：

• 网卡 rx_dropped / tx_dropped 几乎不动（< 0.01%）
• TCP retrans 从 0.02% 涨到 0.15%（有信号但太滞后，应用侧已经报了 5xx 才涨）
• ICMP ping 跨节点 P99 < 2ms（完全正常）
• 应用侧 trace 里网络段耗时从 3ms 涨到 300ms+

事后复盘怀疑是「节点侧 softirq 排队 + iptables 规则匹配 CPU 争抢」导致 TCP ACK 延迟，但当时没有任何一个指标能提前 30s 发出预警——retrans 是结果，不是原因；ICMP 走内核协议栈但不经过 iptables FORWARD 链，所以完全看不到问题。

现象（可复现的）

• 尖峰时段：每天 14:00~16:00（业务高峰）出现 2~4 次，每次 5~20s
• 同节点 Pod 互调完全正常（P99 < 5ms）
• 跨节点 Pod 互调 P99 尖峰到 400~800ms
• 尖峰期间 mpstat 显示目标节点 %soft 从 2% 跳到 12~18%
• tc -s qdisc show dev eth0 的 sent 和 dropped 在尖峰期间无显著变化
• 应用侧（Java）Thread.dump 显示大量线程 WAITING on socket read

已尝试的排查与结果

1. eBPF 挂 tcp_v4_rcv 抓 per-flow RTT：能抓到 RTT 尖峰，但需要逐节点部署，运维成本高；而且 eBPF 探针本身在 softirq 高负载时会不会丢事件？没验证过。
2. ss -ti 定时采样：5s 间隔，粒度太粗，尖峰 5s 就过去了一半。
3. ICMP ping 跨节点矩阵：完全正常，因为 ICMP 不经过 VXLAN 封装路径的 iptables 链（不确定这个理解对不对）。
4. node_exporter 的 node_softirq_processed_total：有信号，但聚合到节点级，看不到是哪个 Pod 的流量受影响。

我想问的具体问题

我想在每个节点上跑一个轻量级的「网络金丝雀」Pod，专门做跨节点 TCP 层探测（不是 ICMP），目标是：

1. 探针设计：用什么方式做 TCP 探测？（nc 端口探测 / 自定义 TCP connect+read 循环 / curl 到固定端点？）包大小怎么定才能触发 iptables 匹配路径但不大到触发 PMTU 问题？
2. 采样间隔：5s 太粗、1s 会不会对节点 softirq 本身造成压力？在 90 节点规模下，每节点 1 个金丝雀 Pod 是否合理？
3. 指标与阈值：我打算采集 TCP connect 耗时 + 首字节延迟（TTFB）+ 小文件传输吞吐。P99 阈值怎么定？是绝对值（如 TTFB > 50ms 告警）还是相对值（如比 10min 滑动均值高 3 倍告警）？
4. 与现有指标的关联：金丝雀的 TCP 延迟尖峰和 node_exporter 的 %soft 尖峰之间，时间差通常是多少？能不能用金丝雀做「提前量」，用 %soft 做「确认」？
5. 有没有更轻的方案：比如直接用 tc filter 做 per-flow 延迟统计，或者用 cgroup v2 的 net_cls 做 per-Pod 网络延迟隔离观测？

期望得到的答案形态

• 一个可落地的金丝雀 Pod 设计（Dockerfile / 探测脚本 / Prometheus exporter 配置），最好有 YAML 可以直接 deploy
• 阈值设定方法论：不是拍脑袋给一个数，而是怎么根据集群规模、业务 P99 目标反推
• 与 eBPF 方案的取舍：什么规模下金丝雀够用、什么规模下必须上 eBPF
• 如果社区有人踩过「金丝雀自身成为噪声源」的坑，请分享

相关参考

• 社区已有讨论《P99 抖动时「网络锅 vs 应用锅」到底怎么分？》(id=1508) 提到「TCP 没断、ping 通、丢包率 0.01%」但 P99 依然飙——正是我遇到的场景
• 《同机房 TCP 重传率 0.4% 却 P99 翻倍》(id=870) 给了 RTO 退避的分析，但我的场景里 retrans 率还很低（0.02%→0.15%），还没到 RTO 翻倍的量级
• 《大包通小包超时：MTU 黑洞与 PMTU 失效》(id=1006) 排除了 MTU 因素（我们 MTU 已统一 1450）