K8s 节点跑 SCHED_FIFO 实时任务，cpuset 静态隔离后仍偶发 200ms 级抖动，邻居进程怎么彻底关？

背景 我在一个 12 节点（4C8G，cgroup v2，K8s 1.28.9，containerd 1.7）的集群上跑一套电机控制闭环，控制周期 5ms，硬实时要求 P99 ≤ 10ms。业务 Pod 用 cpuset 静态绑定 2 核，进程走 SCHED_FIFO priority=99。节点是 dedicated 角色，没有跑其他业务负载。

现象 72h 稳定性测试，P50 稳定在 3.2ms，但 P99 偶发飙到 180~450ms，频率大约每小时 1~3 次。用 perf sched latency + trace-cmd 抓下来，延迟主要来源是：

1. kubelet 的 PLEG 刷新（单次 ~80ms，涉及 /proc 遍历和 API 写入）；
2. containerd-shim 的 cgroup 文件写入（偶发，~15ms）；
3. 同节点上 systemd 的 journal flush 和 cron 触发的 apt/dnf 检查。

已尝试的排查与结果

1. 节点 cordon + 只保留实时 Pod → P99 降到 12ms，但毛刺仍在；
2. 内核参数 isolcpus=2,3 nohz_full=2,3 rcu_nocbs=2,3 → P99 降到 5ms 以内，有效但运维成本高（每个节点要单独维护 GRUB + systemd 配置，K8s 升级时容易丢失）；
3. cgroup v2 的 cpu.weight 把实时 Pod 拉到 10000 → 对 RT 调度器无效（RT 不走 CFS，weight 只影响 CFS 组内分配）；
4. kubelet 的 --pleg-relist-interval 从 1s 调到 10s → P99 改善约 30%，但 PLEG 本身的 /proc 遍历还是会造成瞬时中断；
5. 把 journal 设为 Storage=none、禁掉 cron → 消除了 journal/cron 来源的毛刺，但 kubelet 和 shim 的干扰仍在。

卡点 isolcpus 方案能彻底解决，但运维成本很高：每个节点要单独维护内核启动参数和 systemd 配置，K8s 升级、节点漂移、镜像重建时容易丢失。而且 K8s 1.28 的 kubelet 本身没有提供"让出 CPU"或"降低自身优先级"的机制。

期望得到的答案形态

• 有没有比 isolcpus 更轻量的方案，能在不重启节点、不改内核参数的情况下隔离邻居进程（比如 cgroup v2 的 cpu.max 对 kubelet/containerd-shim 做"软限流"，效果如何？有没有人实测过？）
• 社区里有没有人用 systemd-run 或 chrt 把 kubelet、containerd 进程降到 SCHED_IDLE（priority=0），配合 cpuset 隔离，效果怎么样？
• 如果必须走 isolcpus，有没有推荐的节点初始化方案（比如 DaemonSet + privileged 修改 /proc/cmdline，或者用 K8s Operator / 节点池自定义 AMI 等方式）？
• 从"是否值得"的角度：如果业务负载只占 2 核、节点只有 4 核，isolcpus 的运维成本 vs. 收益，大家一般怎么权衡？