K8s 上跑 1ms 硬实时控制任务，容器化后 P99 抖动从 200us 飙到 1.5ms 怎么排查

背景 我在一家做工业网关的厂里，核心是一个 1ms 控制周期的实时任务（运动控制 + 协议桥），原本裸机跑在 8C/16G 的工控机上，SCHED_FIFO 99，P99 抖动 <200us，跑了三年稳定。今年公司要求统一容器化、上 K8s（1.28.9，cgroup v2，containerd 1.7.13，Calico），同一个二进制、同一台物理机，只是被塞进 Pod。

现象 迁移后 P50 还是 1.001ms 没变，但 P99 抖到 1.2ms，P999 偶尔冲到 1.5ms，硬实时指标直接被打穿。业务方不认，说"容器化前没这个问题"。抓了 3 天 ftrace 看 sched_switch 路径，发现毛刺主要落在：① 控制核被周期性抢占，抢占者不是业务线程；② 抢占窗口高度规律，间隔 ~500ms，和 kubelet 的 pleg / CRI 心跳节奏疑似相关；③ 部分毛刺出现在 cgroup 迁移 / memcg charge 路径上。

已尝试

1. cpuManagerPolicy=static + Pod 独占核 + topologyManager=single-numa-node，控制核与 IRQ、日志核分开；
2. 业务进程 SCHED_FIFO 99，容器内 swappiness=0，transparent_hugepage=never；
3. 关闭 irqbalance，把网卡 IRQ 绑到独立核；
4. 给 Pod 去掉 cpu limit（保留 request），避免 CFS 节流；
5. 尝试过给 kubelet 加 --cgroups-per-qos=false，P99 反而更差，已回退。

期望得到的答案形态

• 一个可复现的排查 checklist：从内核调度路径（tick、nohz、cgroup 层级）→ CRI/kubelet 心跳 → memcg charge → 中断路由，按"先排谁后排谁"的顺序给出来；
• 有没有人踩过"kubelet pleg / CRI stream 心跳落在控制核上"这个坑，是怎么绕开的（独立 cgroup？独立核？还是直接禁掉某些心跳？）；
• cgroup v2 下 memcg 的 charge 路径对硬实时任务是否真的有害，有没有数据；
• 最后给一个"容器化 vs 裸机"的成本收益判断：什么样的实时任务适合容器化，什么样的不该硬上。

不想要"理论上可以"，想要具体命令 / 配置项 / 数据。