K8s 高峰期 Go 服务 p99 抖到 800ms：如何系统性排除 DNS / CNI / conntrack 嫌疑？

【背景】 我是一名有 8 年经验的云原生架构师，目前在维护一个自建 K8s 1.28（containerd 1.6 + Calico v3.26，IPIP 模式，3 控制面 + 12 工作节点，64C/256G 规格）的集群，上面跑着约 40 个 Go 无状态服务。最近 3 周，一个核心网关服务在每天 14:00–16:00 高峰期出现 p99 从平时的 120ms 抖到 800ms+ 的现象，持续 5–15 分钟后自行恢复，且没有伴随 CPU / 内存 / GC 异常。

【现象】

• pprof 抓到的 CPU profile 里，峰值时段 net/http、runtime.gc 占比正常，但 wall time 里 net.Resolver.lookup、dial、readFromPacketConn 明显升高；
• 同一时段 kube-dns Pod 的 CPU 使用率从 150m 飙到 900m，但 P99 查询延迟仅从 3ms 升到 12ms；
• Calico IPIP 模式下，同节点跨 Pod 流量走 lo，跨节点走 tunl0；高峰期节点上 conntrack 表使用率从 35% 冲到 82%（nf_conntrack_count / max）；
• 没有 OOM、没有重启、没有 NetworkPolicy 变更。

【已尝试的排查】

1. kubectl top pod / node-exporter：CPU、内存、网络收发都正常；
2. 在客户端 Pod 里跑 time nslookup 与 time curl：DNS 解析偶发 200ms+，但 curl 到固定 IP 的耗时稳定；
3. 抓 conntrack -S：高峰期 insert_failed 与 early_drop 计数确实在涨；
4. 试过把该服务节点 affinity 收敛到 2 个节点，抖动幅度变小但未消失。

【期望得到的答案形态】 希望社区同学能给出：

1. 一个可复现的排查清单（按嫌疑排序：DNS / CNI / conntrack / 上游服务），每一步给出具体的命令、指标名与判断阈值；
2. conntrack 表压力在 Calico IPIP 模式下到底会不会成为 p99 抖动主因？如果是，推荐的调优参数（nf_conntrack_max、hashsize、notrack 的 NetworkPolicy 写法）与风险点；
3. kube-dns 在 40 个服务、单集群场景下的合理副本数与 --cache-ttl-min 建议值，以及是否值得引入 coredns-autoscaler 或 node-local-dns 的判据。

我会把后续数据贴回本帖。