PDB怎么配置，先看工作负载能承受几个副本同时不可用，而不是先选 `minAvailable` 还是 `maxUnavailable`。PodDisruptionBudget 约束的是自愿中断，例如节点维护、集群升级、主动驱逐；它不能阻止节点故障、容器崩溃或应用自身异常。因此，PDB 是高可用保护的一部分，不是高可用本身。
如果你正在建立 Kubernetes 生产规范，可以把副本、配额、升级和维护窗口放到同一套平台规则中，避免 PDB 成为孤立配置。图型选择说明：本文使用决策关系、字段边界矩阵和验证流程三类图，服务 PDB 配置判断。
图1：PDB 在节点维护、驱逐请求和工作负载副本之间的决策关系
PDB怎么配置：先确定不可用预算
Kubernetes Pod Disruptions 官方文档[1]说明，PDB 用于限制自愿中断期间同时不可用的 Pod 数量。配置前要先回答一个问题：这个服务在维护窗口内最低需要多少副本保持可用？
常见选择如下：
| 副本数 | 推荐思路 | 风险提醒 |
|---|---|---|
| 1 | 通常不建议配置阻断型 PDB | 单副本本身没有冗余 |
| 2 | 可设置 `maxUnavailable: 1` | 维护时只保留 1 个副本，容量要够 |
| 3–5 | 多数服务可用 `maxUnavailable: 1` | 配合滚动升级策略检查 |
| 6+ | 可按百分比设置 | 注意四舍五入带来的预算变化 |
副本规模决定预算表达方式
关键判断：PDB 保护的是“主动驱逐时不要同时下线太多副本”，不是保证业务永远可用。
minAvailable 与 maxUnavailable 怎么选
`minAvailable` 表示至少保留多少可用 Pod，`maxUnavailable` 表示最多允许多少 Pod 不可用。两者不能同时配置。Kubernetes PodDisruptionBudget API Reference[2]说明，这两个字段都可以使用整数或百分比，但实际效果要结合副本数计算。
一般建议：
- 副本数稳定且较少时，用 `maxUnavailable: 1` 更直观。
- 需要表达最低可用容量时，用 `minAvailable`。
- 副本数经常被 HPA 调整时，谨慎使用百分比，并验证边界。
- 单副本服务不要用 PDB 伪装高可用，应先补副本或降级策略。
示例：
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: checkout-pdb
spec:
maxUnavailable: 1
selector:
matchLabels:
app: checkout这段配置表示自愿中断过程中，带有 `app=checkout` 标签的 Pod 最多允许 1 个不可用。它并不保证节点故障时一定保留副本，因此还要配合反亲和、拓扑分布和容量规划。
图2：不同副本数下 minAvailable 与 maxUna
PDB 与滚动升级、节点维护会互相影响
PDB 配得太严格，会让节点维护和集群升级卡住；配得太宽，又无法保护服务可用性。因此 PDB 要和 Deployment 的滚动升级策略一起看。
上线前至少检查：
- Deployment 副本数是否大于 1。
- `maxUnavailable` 是否与滚动升级策略冲突。
- Pod 是否有正确 readinessProbe，否则可用性判断会失真。
- Pod 是否分布在多个节点或可用区。
- 节点维护流程是否使用 eviction，而不是直接删除节点上的 Pod。
如果节点维护命令一直卡住，可以查看 PDB 状态：
kubectl get pdb
kubectl describe pdb checkout-pdb
kubectl get pods -l app=checkout -o wideKubernetes API-initiated Eviction 官方文档[3]说明，驱逐 API 会遵守 PodDisruptionBudget；这也是为什么直接删除 Pod 和通过驱逐 API 维护节点的行为边界不同。
单副本服务配置 PDB 反而可能制造误解
单副本服务没有冗余，PDB 不能凭空制造高可用。如果给单副本配置 `minAvailable: 1`，节点维护时它可能阻止驱逐，让维护流程卡住；如果不配置，维护时又可能短暂不可用。
这不是 PDB 的问题，而是服务本身缺少冗余。更合理的选择是：
- 能扩副本的服务先扩到 2 个以上。
- 不能扩副本的服务明确维护窗口和业务降级方案。
- 有状态服务先确认存储、锁、主从和恢复机制。
- 把单副本风险写入变更审批和演练清单。
PDB 不应成为“看起来有高可用”的配置装饰。
验证 PDB 要模拟维护路径
配置 PDB 后，最好在测试环境模拟一次节点维护或驱逐，而不是只看 YAML 通过。
图3：从 PDB 配置、驱逐请求到节点维护完成的验证流程
验证时可以观察：
- PDB 的 `ALLOWED DISRUPTIONS` 是否符合预期。
- 驱逐一个 Pod 后服务是否仍可用。
- readinessProbe 是否及时反映可用性。
- 滚动升级是否被 PDB 长时间阻塞。
- 告警是否能覆盖副本不足和驱逐失败。
小结
PDB 配置的关键是不可用预算。先确定服务能承受几个副本不可用，再选择 `minAvailable` 或 `maxUnavailable`；同时检查副本数、探针、滚动升级、节点分布和维护流程。PDB 能降低自愿中断风险，但不能替代副本冗余、容量规划和故障恢复。
参考资料
- [1] Kubernetes Pod Disruptions – 官方文档
- [2] Kubernetes PodDisruptionBudget API Reference
- [3] Kubernetes API-initiated Eviction – 官方文档
常见问题
1. PDB怎么配置才适合大多数 Deployment？
多数 3 个以上副本的无状态服务，可以从 `maxUnavailable: 1` 开始，再结合容量和 SLO 调整。副本数较少、容量紧张或有状态服务，需要单独评估，不建议套模板。
2. PDB 会影响 HPA 扩缩容吗？
PDB 不直接控制 HPA，但 HPA 改变副本数后，会影响不可用预算的实际计算。使用百分比配置时尤其要注意副本数变化后的四舍五入结果。
3. 节点 drain 卡住一定是 PDB 配错了吗？
不一定。可能是 PDB 过严，也可能是 Pod 没有 readiness、应用副本不足、控制器异常或节点维护方式不正确。应先 `describe pdb` 看允许中断数，再看 Pod 分布和事件。
4. StatefulSet 可以配置 PDB 吗？
可以，但要谨慎。StatefulSet 还涉及存储、主从角色、顺序更新和应用层一致性。PDB 只能约束主动驱逐数量，不能保证数据层自动安全切换。
