PodDisruptionBudget（PDB）是Kubernetes中用于约束自愿中断（如kubectl drain、控制器缩容、CA驱逐）时最大不可用Pod数或最小可用Pod数的机制，确保业务不中断；它不干预非自愿中断（如节点宕机、OOM），也不影响滚动更新（由maxSurge/maxUnavailable控制），且minAvailable与maxUnavailable互斥，需通过labelSelector精准匹配目标工作负载。
在 Kubernetes 中做节点或组件更新时，业务不中断的关键不是“能不能停”，而是“能停几个、停多久”。PodDisruptionBudget（PDB）正是为此设计的控制机制——它不阻止更新操作本身，而是确保自愿中断（如 kubectl drain、滚动升级、节点腾空）不会一次性带走太多 Pod，从而守住服务底线。
明确 PDB 只管“自愿中断”
PDB 对以下场景生效：
-
节点腾空（
kubectl drain）：这是最典型的应用场景，PDB 会实时检查当前健康 Pod 数是否满足设定阈值，才允许逐出 - 控制器缩容（如 Deployment 缩容副本数）：缩容动作受 PDB 约束，不会违反 minAvailable 或 maxUnavailable
- 集群自动伸缩器（CA）驱逐 Pod 以回收节点：只要驱逐由 API 发起且属自愿类型，PDB 就参与校验
它不管非自愿中断，比如节点宕机、Pod OOM 被杀、网络分区导致失联。这些靠多副本 + 反亲和 + 健康检查来兜底。
选对参数：minAvailable 还是 maxUnavailable？
二者互斥，选哪个取决于你更习惯“保下限”还是“控上限”：
-
用
minAvailable: 2：适合有状态应用（如 etcd、ZooKeeper、Redis 集群）。例如 5 副本集群，仲裁需 ≥3，那就设minAvailable: 3，确保任何时候至少 3 个 Pod 在提供服务 -
用
maxUnavailable: 1或maxUnavailable: 25%：适合无状态前端、API 服务。比如 8 副本的 Web 应用，设maxUnavailable: 25%即最多允许 2 个 Pod 同时不可用，其余 6 个持续响应流量
注意百分比计算向下取整：minAvailable: 90% 在 10 副本时是 9 个，但在 3 副本时是 2（不是 2.7→3），这点容易误判可用余量。
绑定目标：Label Selector 必须与工作负载一致
PDB 不会自动关联 Deployment 或 StatefulSet，必须手动对齐标签：
- 检查你的 Deployment 的
spec.selector.matchLabels，例如：app: user-api - PDB 的
spec.selector.matchLabels必须完全一致，否则 PDB 形同虚设 - 常见错误：Deployment 用了
app.kubernetes.io/name: user-api，但 PDB 写成app: user-api，导致匹配失败
建议在 CI/CD 流水线中加入 YAML 校验步骤，比对两者 selector 是否一致。
应对异常 Pod：启用 unhealthyPodEvictionPolicy
Kubernetes v1.26+ 支持新字段 unhealthyPodEvictionPolicy，解决长期卡在 CrashLoopBackOff 或未就绪的 Pod 拖慢节点腾空的问题：
-
unhealthyPodEvictionPolicy: IfHealthyBudget（默认）：只驱逐健康 Pod；如果所有 Pod 都不健康，kubectl drain会卡住 -
unhealthyPodEvictionPolicy: AlwaysAllow：允许驱逐不健康但仍在 Running 状态的 Pod，加快维护节奏，适用于已确认可丢弃的异常实例
生产环境推荐显式配置为 AlwaysAllow，避免因个别故障 Pod 导致整批节点无法滚动更新。
验证与观测：别只看创建成功
创建 PDB 后务必验证实际效果：
- 运行
kubectl get pdb -n查看CURRENT HEALTHY和DESIRED HEALTHY是否匹配预期 - 执行
kubectl drain模拟腾空，观察是否被拒绝及提示原因--dry-run=client -o wide - 监控
policy.poddisruptionbudgets.status.currentHealthy指标（若接入 Prometheus），设置告警：当currentHealthy 持续 2 分钟即触发人工介入
真正的保障不在 YAML 写得漂亮，而在每次更新前确认预算真实生效。
