K8s 1.28 PDB 与 topologySpreadConstraints 同时存在时，节点故障后 Pod 是否会被调度死锁？

背景 我维护一个 12 节点（16C64G，K8s 1.28.9，containerd 1.7.13，cgroup v2，内核 5.15，Calico 路由模式）的生产集群，3 个可用区（A/B/C），每区 4 节点。核心服务是一个 Java 17 无状态 API（8 副本），Deployment 里同时配了 PDB（minAvailable=6）和 topologySpreadConstraints（topologyKey: topology.kubernetes.io/zone, maxSkew: 1, whenUnsatisfiable: DoNotSchedule）。

现象 上周做一次计划内维护，drain 了可用区 A 的一台节点（该节点上有 3 个副本）。预期调度器把 3 个 Pod 迁到 B/C 区。实际观察到：2 个 Pod 成功调度到 B 区，第 3 个 Pod 一直 Pending，事件日志反复出现 0/12 nodes available: 4 node(s) didn't satisfy topology spread constraint (maxSkew exceeded)。同时 PDB 显示 minAvailable=6 已满足（B/C 区各有 3 个副本），但 TSC 的 maxSkew=1 要求每 zone 副本数最多差 1：A 区 0、B 区 4 → skew=4 > 1，TSC 直接阻断了调度。

已尝试的排查

1. 临时把 whenUnsatisfiable 改成 ScheduleAnyway → Pod 立刻调度成功，确认 TSC 是阻塞点；
2. 把 maxSkew 从 1 调到 2 → 仍 Pending（A 区 0、B 区 4，skew=4 > 2）；
3. 把 maxSkew 调到 4 → 调度成功，但此时 TSC 形同虚设；
4. 翻 K8s 1.28 调度器源码 pkg/scheduler/framework/plugins/topologyspread，确认 DoNotSchedule 模式下 TSC 是硬过滤，不满足的节点直接被剔除；
5. 查 PDB 逻辑，确认 PDB 只在"可中断性"检查阶段生效（CheckNode 阶段），不参与调度过滤，两者无协调机制。

卡点 PDB 管"能不能驱逐"，TSC 管"能不能调度"，两套机制独立运作。节点故障导致某 zone 副本归零时，PDB 允许迁移（minAvailable 满足），但 TSC 阻止迁移到"已经多"的 zone。调度器不会"放宽 TSC 以满足 PDB"，也不会"因 PDB 而忽略 TSC"。

期望得到的答案形态

1. K8s 1.28 / 1.29 中，PDB 与 TSC（DoNotSchedule）的交互是否有官方文档或 KEP 明确说明优先级？
2. 生产环境中 PDB + TSC 同时配置时，有没有推荐的"兜底策略"（比如 TSC 用 ScheduleAnyway + 监控告警替代 DoNotSchedule）？
3. 是否有人在 K8s 1.28+ 上遇到过类似的 PDB/TSC 死锁，最终怎么解决的？