Istio sidecar 的「P99 延迟税」到底怎么量化到可复现？压测有/无 mesh 差 0.8ms，但 P999 抖动太大，缺一个能进 CI 的基线方法

【背景】 我们是 40 个 Go gRPC 无状态服务，K8s 1.28 自建集群（阿里云 + 自建混合），Istio 1.21 全量 sidecar 注入（mTLS + 全链路遥测）。核心下单链路 SLO 是 P99 < 80ms，现在实测 P99 常年贴线 74–79ms，财务要预算、安全要 mTLS、我这边要延迟——三方吵架吵了三轮。 争议焦点不是「要不要网格」，而是：如果要摘掉某个服务的 sidecar 换成内嵌 SDK，到底能省回多少 P99？没有这个数字，任何架构决策都是拍脑袋。

【现象】 我上周用 k6 做了一组 A/B：同一套压测流量（固定 RPS 阶梯 200→2000），一组命名空间开 mesh 注入、一组打 sidecar.istio.io/inject=off，只压下单主链路（3 跳 gRPC 串联）。 结果：

• 平均延迟差：有 mesh 比无 mesh 高 0.8ms（P50 层面，可复现，三次跑标准差 <0.1ms）
• 但 P999 层面：有 mesh 的 P999 在 118–142ms 之间跳，无 mesh 也有 96–112ms 的抖动，A/B 两组 P999 的差值三次跑分别是 14ms / 21ms / 9ms——这个方差大到没法写进评审结论
• 更诡异的是：无 mesh 组跑在「干净的」节点上（没有 Envoy 争抢 CPU 缓存），有 mesh 组随机落到不同节点，我怀疑节点位置噪声 > sidecar 本身的贡献，但我没有数据证明这一点

【已尝试的排查】

1. k6 固定 RPS + 固定 10 分钟窗口，跑 3 次取中位数——P50 稳定，P999 依然抖（上面数据）
2. 把两组压测 pod 用 nodeName 固定到同物理节点（有 mesh 组 sidecar 与 main 同 pod 天然共节点）——P999 方差没明显改善，怀疑是内核软中断 / NUMA 的问题
3. 在 main 容器里开 pprof，对比两组 handler 内耗时——几乎一样，说明差异全在进程外（loopback + Envoy 转发），但 pprof 看不到这部分
4. 想用 eBPF 抓 loopback 路径耗时（bpftrace 打 tcp:tcp_cleanup_timewait 之类）——刚起步，tracepoint 选不准，还没出数据
5. 翻过热榜《Sidecar 正在被 eBPF 吃掉》(id=1370) 的内存数据、《Istio 的三秒 vs 你的 P99》(id=219) 的定性讨论，但没有一篇给出延迟税的测量方法论

【期望得到的答案形态】 不想要「sidecar 有开销，看你们情况」这种结论，想要：

1. 一套可复现的测量方案：怎么把「sidecar 单请求延迟税」从节点噪声、GC、内核抖动里剥出来？固定节点 / cgroup cpuset / 关中断亲和，哪个最有效？有没有人试过用 taskset + isolcpus 做隔离基线？
2. P999 方差收敛的经验值：你们团队的 A/B 压测，P999 差值的标准差能压到多少？跑几轮、什么窗口长度才敢下结论？
3. 有没有人把这套测量做成 CI 回归（比如每次升级 Envoy 版本自动跑延迟税基线，超 5% 报警）？工具链长什么样？
4. 加分项：eBPF 抓 sidecar loopback 路径的 tracepoint 选点经验（我知道 kprobe 打 Envoy 不现实，想听数据面内核侧的打法）

带真实数据（哪怕一个服务的）的都欢迎，最好附命令 / 配置片段，方便我直接复现。