直接回答：PDB 约束“主动运维操作”（drain、节点升级、集群缩容这类自愿中断）期间应用的最小可用副本数（minAvailable）或最大不可用数（maxUnavailable）。它不防非自愿故障（节点宕机、OOM），只约束 Eviction API 路径的驱逐。卡住的原因：drain 发的是驱逐请求，如果驱逐某个 Pod 会让可用数跌破 PDB 阈值，驱逐被持续拒绝，节点维护就永远停在那。
展开解析：卡死的典型配置：副本数 2 配 minAvailable: 2——任何驱逐都违规，PDB 形同“禁止维护”；单副本应用配 minAvailable: 1 同样无解。正确姿势是容量与 PDB 匹配：期望容忍一个节点维护就留足冗余副本并设 maxUnavailable: 1 或 25%。诊断：kubectl get pdb 看 ALLOWED DISRUPTIONS 为 0 的就是瓶颈；事件里 TooManyRequests（429）来自 eviction 子资源。其他易忽略点：PDB 按 label selector 圈 Pod，selector 写错会圈到无关负载或一个都圈不到（后者静默失效，保护了个寂寞）；滚动更新（Deployment 自身 maxUnavailable）不走 Eviction API、不受 PDB 约束，别指望 PDB 保护发布期；抢占式驱逐（高优先级 Pod 抢占）也绕过 PDB。实践建议：PDB 与就绪探针配合（新副本 Ready 才算可用），多副本有状态服务（如 Kafka、Elasticsearch）必须配 PDB 防运维误伤半数节点。
追问方向：驱逐 API 与直接删除 Pod 有何区别？PDB 该如何量化取值？
（约 480 字）