CPU Manager、Topology Manager、QoS 三件套在混部节点上怎么取舍，谁先开谁反噬

【背景】 做了 8 年嵌入式，最近两年重心放在容器化和 K8s 运维。站内已经有很多单点的好内容：CPU limit 触发 CFS 节流把 P99 从 45ms 打到 2.1s 的复盘、CTE 物化导致 JOIN 变慢、还有我自己在双路 32C 节点上问过的跨 NUMA 调度抖动。但这些都是「单颗旋钮拧到出问题再回头修」的视角。我最近被一个更现实、也更难的问题卡住了：在共享节点、没有独占高性能集群预算的前提下，CPU Manager（cpuset 独占核）、Topology Manager（NUMA 亲和）、QoS（Guaranteed/Burstable/BestEffort）这三件事，到底该按什么顺序、在什么负载下开，开了之后各自的反噬点是什么。

我把它拆成几个我目前踩到或看到的矛盾点：

1. CPU Manager 开了 static 策略后，只有 Guaranteed 且 request==limit 的 Pod 才能拿到独占核。一旦某个服务为了拿独占核被迫把 limit 设成整数核，CFS 节流虽然没了，但「邻居噪声」换成了「独占核被自己打满后的硬切」——对 burst 型 Go 网关这种负载，反而可能比共享核更抖。
2. Topology Manager single-numeric 在双路机器上强制单 NUMA，听起来对延迟友好，但一旦节点上 NUMA 核被瓜分完，新 Pod 直接 Pending 或退化成 best-effort 调度，容量利用率肉眼可见下降。
3. QoS 这块，很多团队为了拿 cpuset 把 Burstable 全改成 Guaranteed，结果内存 limit 一设就 OOMKilled 的雷多了，等于把一个抖动问题换成了一个可用性问题。

【我的倾向】 我倾向的排序是：先把 QoS 和 limit 的「底线」定对（避免 CFS 节流和 OOM 两个硬故障），再按负载形态决定要不要上 cpuset，Topology Manager 只在「单 Pod 延迟敏感 + 节点核数充裕 + 负载形态稳定」时才开，否则宁可不开。理由很务实：cpuset 和 Topology 都是「用容量换延迟」的交易，而 QoS/limit 是「别出硬故障」的底线，底线没守住之前谈延迟是空中楼阁。嵌入式里我常说一句话：先保证不会掉线，再谈抖动。

【想听大家怎么选】 具体想请教三个点：

1. 你们线上有没有「开了 CPU Manager 之后 burst 型服务反而更抖」的案例？怎么回退的？
2. Topology Manager 你们开的是 single-numeric 还是 best-effort？在双路机器上 best-effort 的实际收益和 single-numeric 差多少？
3. 混部节点上，你们是怎么给「延迟敏感服务」和「吞吐型批处理」做隔离的，是物理分池、还是 cpuset + 优先级 + 驱逐策略的组合拳？

欢迎贴你们的 CPU Manager / Topology Manager 配置片段、QoS 分布、或者踩过的坑，尤其是「开了之后容量利用率掉到多少」的量化数据。我先说：这个话题我判断没有标准答案，只有「在你这个负载形态 + 节点规格 + 预算约束下哪种组合代价最小」的取舍。