K8s VXLAN overlay（Calico）跨节点 Pod 互访 P99 偶发 80ms+：underlay 正常，怎么把 overlay 封装开销与节点 datapath（iptables/Felix）CPU 争抢拆开来观测？

背景

我 3 年网络工程背景，现在在保一个 K8s 集群：约 60 节点，Calico VXLAN overlay（iptables 模式，不是 BPF 模式），节点双口 25G 网卡，内核 5.10。业务方反复反馈「跨节点 Pod 调用偶发变慢，同节点调用正常」，我抓 underlay 看不出问题，和 SRE 扯皮了两周，想请社区给一套客观的拆解方法。

现象

• 同节点 Pod→Pod：P99 < 5ms，稳定；
• 跨节点 Pod→Pod：P50 约 8ms，P99 偶发 80–150ms，每次持续 2–5s 后回落，每天 3–5 个尖峰；
• 尖峰期 underlay 物理口 sar -n DEV 看吞吐峰值只到链路 40% 左右，ethtool -S 无丢包、无错包、无 dropped；
• 关键：在 Pod 内 ping 对端 Pod IP（走 overlay 内层 IP），时延 P99 同样上到 60ms+，说明慢在 overlay 数据面，不是应用 handler；
• 被调节点 ksoftirqd/ 对应核 CPU 在尖峰期偶尔冲到 80%+；
• ss -ti 看跨节点 TCP 流在尖峰期 rtt 升到 50ms+，但重传 0。

已尝试的排查

1. 两端 tcpdump 抓包，比对 overlay 内层 IP 包在源/目的机的 in、out 时间戳差，确认耗时在传输/封装路径，不是两端应用处理；
2. ethtool -S + sar -n DEV 排除物理链路丢包/带宽打满；
3. 查 Calico Felix 日志、iptables 规则链长度（iptables -t nat -S | wc -l 已经 600+ 条），怀疑 datapath 规则链太长；
4. perf stat -e context-switches,cpu-migrations + mpstat -P ALL 1 看被调节点软中断 CPU 争抢；
5. 怀疑是「VXLAN 封装 + 长 iptables 规则链」导致 per-packet 成本上升，但没有方法把封装开销和 datapath CPU 争抢定量拆开，卡在这。

期望得到的答案形态

• 一套把「overlay 封装开销」「节点 datapath（iptables/Felix/OVS）CPU 争抢」「underlay 物理链路」三层逐层排除的观测方法：每层用什么指标/工具、看到什么数值就能判定「这一层没问题」；
• 怎么定量测出 VXLAN 封装本身带来的 per-packet CPU/时延成本（比如裸 IP 转发 vs 封装转发的对比实验，或 eBPF uprobe 在 vxlan_xmit 上的计时）；
• iptables 模式 vs Calico BPF 模式在这种「规则链长 + 跨节点」场景下，可观测性和性能差异到底多大，生产上大家怎么选；
• 生产上怎么把 overlay 网络的可观测性做进日常监控（eBPF / 主动探针 / 节点侧 datapath 指标），以及踩过的坑。

如果社区里有人做过「underlay 全绿但 overlay 慢」的归因，或者用 eBPF 把封装路径计时拆出来过，求具体命令和判读口径。