K8s 1.28 节点上 Go 实时采集 sidecar 被普通 Pod 抢占：cpuset + cgroup RT 怎么配才稳？

【背景】我在一个 8 节点（32C128G，Kubernetes 1.28.4，containerd 1.7.13，内核 5.15.0-91，cgroup v2）生产集群上，部署了一个 Go 1.22 的实时数据采集 sidecar（4C2G，SCHED_FIFO 95，绑核 0-3，配了 2G hugepage，采集周期 1ms，P50 延迟稳定在 180μs）。sidecar 跟主容器（一个普通 Java 订单服务，12C8G）共 Pod。

【现象】过去两周观察到 sidecar 的 P99 延迟间歇性抖到 35ms+（正常应该 <1ms），抖动窗口大约 200ms~1s，频率不高（每小时 3~5 次）。抖动时段同节点的 Java 主容器正好在做 GC 或大对象分配，CPU 打满。dmesg 没有 OOM，/sys/fs/cgroup/cpu.stat 里 throttling 计数也没涨。

【已尝试的排查与结果】

1. 把 sidecar 的 cpu limit 从 4 提到 8，P99 抖动仍然存在，说明不是 CPU 配额不够，而是调度抢占；
2. 把 sidecar 进程从 SCHED_OTHER 改成 SCHED_FIFO 95，抖动明显减少但没消除；
3. 给 sidecar 单独绑核（cpuset.cpus=0-3），主容器绑 4-15，抖动仍然存在，怀疑是 hugepage 缺页或 NUMA 跨节点访问；
4. 把 hugepage 从 2G 降到 1G，抖动反而更频繁；
5. 用 perf stat 抓了抖动窗口，看到 context-switches 在抖动期涨了 40 倍，但 cache-misses 变化不大。

【期望得到的答案形态】

• 一套可复现的 cgroup v2 + cpuset + RT 优先级配置（具体到每个文件、每个值）；
• hugepage 在 cgroup v2 下的正确挂载方式（hugepages-2Mi vs hugepages-1Gi 怎么选）；
• 如何判断是 CPU 抢占、内存缺页，还是 NUMA 跨节点访问；
• 有没有更稳的隔离方案（比如把 sidecar 独立成单节点 DaemonSet + 独占核）。