Kubernetes 如何配置 PodDisruptionBudget 保证高可用

PDB仅约束自愿驱逐（如drain、缩容），不防节点故障或OOM；需配合副本数、反亲和、探针等才能保障高可用；minAvailable适合法定人数服务，maxUnavailable适合弹性场景；单副本配PDB会导致drain卡住。

PodDisruptionBudget（PDB）不是“开了就高可用”，而是要在自愿驱逐场景下守住服务底线的精准约束。它不防节点宕机、OOM 或误删，只拦 kubectl drain、集群缩容、滚动维护这类你主动发起的操作。配对合理、配合探针和容忍度，才能真正起效。

明确 PDB 的适用边界

PDB 只响应自愿中断，比如：

1. kubectl drain node-1 排空节点
2. Cluster Autoscaler 缩容空闲节点
3. 节点原地升级或打补丁

它对以下情况完全无效：

1. 节点突然失联、硬件故障、内核 panic
2. Pod 因内存超限被 OOMKilled
3. 手动执行 kubectl delete pod
4. 污点触发的自动驱逐（除非配了对应容忍）

所以单靠 PDB 不能解决高可用，必须和副本数、反亲和性、就绪探针一起用。

选对参数：minAvailable 还是 maxUnavailable？

二者互斥，按业务习惯选其一：

1. minAvailable：适合有法定人数要求的服务，比如 etcd（至少 3 个存活）、ZooKeeper。写死数字或百分比，如 minAvailable: 2 或 minAvailable: "75%"
2. maxUnavailable：更适合弹性伸缩场景，尤其用了 HPA 的应用。例如 maxUnavailable: 1 表示无论副本扩到 5 还是缩到 3，每次最多只允许 1 个不可用；maxUnavailable: "20%" 更灵活

⚠️ 避免给单副本 Deployment 配 PDB——一旦设了 minAvailable: 1，kubectl drain 就永远卡住，因为没地方腾挪。

精准关联 + 必要协同

PDB 生效依赖三个关键动作：

1. selector 必须严格匹配 Pod 标签：和 Deployment/StatefulSet 中 spec.template.metadata.labels 完全一致，否则 PDB 形同虚设
2. 就绪探针（readinessProbe）必须启用且合理：探测失败后 Pod 自动从 Service Endpoint 移除，避免流量打到半死状态
3. 关键 Pod 加长容忍时间：比如网关类 Pod，配置 tolerationSeconds: 300，防止节点短暂 NotReady 就被驱逐

别把 livenessProbe 设得太激进——频繁重启可能让 PDB 统计误判，导致驱逐被意外阻塞。

验证是否真生效

配完别只看 YAML 是否创建成功，要实测：

1. 查状态：kubectl get pdb -n your-ns 看 MIN AVAILABLE 和 CURRENT HEALTHY 是否对得上
2. 模拟排空：kubectl drain node-x --dry-run=client -v=6，观察日志里是否出现 disruption budget not satisfied 提示
3. 监控指标：policy_pod_disruption_budget_status_conditions{condition="DisruptionsAllowed"} == 0 是危险信号，需立即排查

不复杂但容易忽略。