PodDisruptionBudget怎么用？K8s高可用保护实践

PodDisruptionBudget怎么用，是很多团队进入 Kubernetes 生产阶段后才会遇到的问题。Deployment、StatefulSet 和多副本服务可以提升可用性，但在节点维护、集群升级、节点缩容、驱逐 Pod 时，如果没有明确的中断预算，多个副本仍可能在短时间内同时不可用。PDB 的作用，就是为计划性中断设置保护边界，让平台在维护动作中尊重业务的最低可用要求。

本文评估口径

本文讨论的是 Kubernetes 中计划性中断的高可用保护，例如节点排空、集群版本升级、节点池缩容、运维迁移等。PDB 并不能阻止硬件故障、进程崩溃、节点宕机这类非计划性故障，也不能代替多可用区部署、探针、滚动发布和应用自身容错。

理解这个边界很重要。PDB 是高可用体系中的一道治理规则，不是让应用永远不中断的保险。它保护的是“平台主动驱逐 Pod 时，至少保留多少可用副本”。

PDB解决的具体问题

在没有 PDB 的情况下，平台执行节点维护时可能会连续驱逐多个 Pod。对于一个 3 副本服务，如果多个副本恰好集中在同一节点，或者维护流程并发过高，就可能短时间只剩 1 个甚至 0 个可用副本。即使 Deployment 很快拉起新 Pod，镜像拉取、调度、启动和就绪探针也需要时间。

PDB 通过 minAvailable 或 maxUnavailable 约束驱逐行为。例如要求至少 2 个副本可用，节点排空时 Kubernetes 就不会允许把可用副本数降到 2 以下。这样可以给业务留下恢复窗口，也能迫使运维动作按更稳妥的节奏执行。

minAvailable和maxUnavailable怎么选

PDB 有两种主要写法：minAvailable 表示至少保持多少 Pod 可用，maxUnavailable 表示最多允许多少 Pod 不可用。二者不要同时使用。

对于固定 3 副本的关键服务，常见做法是 minAvailable 设为 2；对于 10 个以上副本的无状态服务，可以考虑 maxUnavailable 为 10% 或 20%。如果服务由 HPA 管理副本数，百分比写法更灵活，但要在最小副本数下验证是否仍满足预期。

基础配置示例

下面示例要求 production 命名空间中带有 app: payment-api 标签的 Pod，至少保持 2 个可用副本。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: payment-api-pdb
  namespace: production
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: payment-api

应用后可以查看状态：

kubectl get pdb payment-api-pdb 
  -n production

如果需要观察更详细的允许中断数量，可以执行：

kubectl describe pdb payment-api-pdb 
  -n production

PDB 的 selector 必须和目标 Pod 标签准确匹配。很多配置无效，并不是 PDB 机制有问题，而是标签选择器没有选中任何 Pod，或者同一个服务的标签在不同版本中不一致。

PDB与Deployment滚动发布的关系

PDB 主要约束驱逐 API 触发的计划性中断，而 Deployment 的滚动发布由自身的 maxUnavailable、maxSurge 和就绪状态控制。两者都与可用副本有关，但作用层不同。

如果 Deployment 滚动发布已经允许较多不可用副本，而 PDB 又要求很高的可用数，发布可能变慢甚至卡住；如果 PDB 过于宽松，节点维护时又可能影响业务。因此建议把 Deployment 发布策略和 PDB 放在同一张变更清单里评审，而不是分别由开发和平台团队独立配置。

PDB与节点维护的协同

节点维护通常会执行 cordon 和 drain。cordon 阻止新 Pod 调度到该节点，drain 会尝试驱逐节点上的 Pod。此时 PDB 会参与判断：如果驱逐某个 Pod 会违反中断预算，drain 会等待或失败。

这不是异常，而是 PDB 正在发挥作用。运维团队不应简单使用强制参数绕过保护，而应先确认服务副本数、跨节点分布、Pod 就绪状态和 PDB 规则是否合理。对于关键业务，维护窗口中等待 PDB 释放预算，比强制驱逐造成服务不可用更可控。

哪些场景特别需要PDB

核心在线服务、有状态组件、启动慢的服务、由 HPA 管理副本数的服务、多团队共享集群，都更应该评估 PDB。它能把业务可用性要求显式交给调度与运维流程，避免维护动作只从节点资源视角出发，而忽略业务副本的真实承载能力。

PDB配置常见误区

单副本服务配置严格PDB

如果服务只有 1 个副本，并配置 minAvailable: 1，那么任何计划性驱逐都会被阻止。这可能导致节点无法排空、集群升级受阻。单副本服务要么接受维护中断，要么先提升为多副本，再谈 PDB 保护。

PDB规则比副本数还严格

例如 3 副本服务要求 minAvailable: 3，意味着不允许任何计划性中断。除非业务确实不能承受一个副本临时不可用，否则这种配置会让维护流程非常困难。

忽略Pod反亲和或拓扑分布

PDB 只规定可用数量，不保证副本分散在不同节点或不同可用区。如果 3 个副本都在同一节点，PDB 可以阻止驱逐，但无法消除节点故障带来的风险。应配合拓扑分布约束、反亲和和合理的节点池设计。

把PDB当作故障恢复机制

PDB 对非计划性故障无能为力。节点突然宕机、容器崩溃、内核故障、磁盘异常不会先征求 PDB 同意。真正的高可用仍要依赖多副本、健康检查、快速重建、跨故障域分布和应用容错。

生产落地建议

建议从核心服务开始梳理 PDB，而不是一次性给所有工作负载套模板。每个服务至少记录三个信息：期望副本数、最低可用副本数、维护场景下可接受的恢复时间。然后再决定使用 minAvailable 还是 maxUnavailable。

对于平台团队，可以把 PDB 纳入发布规范：生产服务必须说明是否需要 PDB；如果不需要，要说明原因；如果需要，要和 Deployment 副本数、滚动发布策略、HPA 最小副本数一起评审。这样 PDB 才能成为高可用治理的一部分，而不是零散 YAML。

常见问题

PDB会阻止Pod崩溃吗？

不会。PDB 只影响计划性驱逐，例如节点排空、集群维护、节点缩容等。容器进程崩溃、节点故障、OOM、探针失败导致的重启不受 PDB 阻止。因此 PDB 不能替代健康检查、资源限制、应用容错和跨节点部署。

drain节点时PDB导致卡住怎么办？

首先确认卡住是否符合预期。如果驱逐会让可用副本低于预算，等待是正确行为。可以临时增加副本数、等待新副本 Ready、调整维护并发，或在确认业务可承受的情况下修改 PDB。不要直接绕过保护，除非已经完成风险评估和业务确认。

HPA场景下PDB怎么设置？

HPA 场景要重点看最小副本数。假设 minReplicas 为 2，却配置 minAvailable: 2，那么低流量时任何计划性驱逐都会被阻止。更稳妥的做法是根据业务高可用要求提高 minReplicas，或使用 maxUnavailable 的百分比并验证低副本场景。

StatefulSet需要PDB吗？

通常更需要。许多有状态应用恢复慢、成员变更敏感、数据同步复杂，计划性中断的节奏更需要控制。但 StatefulSet 的 PDB 设计要结合应用自身仲裁机制、主从角色、存储恢复时间和维护流程，不能简单照搬无状态服务策略。

结语

PodDisruptionBudget怎么用，关键在于把业务最低可用要求转化为 Kubernetes 能执行的驱逐规则。它不能消除所有故障，但能让节点维护、集群升级和资源迁移更有边界。对于生产集群，PDB 应与副本数、反亲和、拓扑分布、滚动发布和监控告警一起设计，才能真正提升 K8s高可用水平。