pdb仅约束自愿驱逐（如drain、缩容），不防节点故障或oom；需配合副本数、反亲和、探针等才能保障高可用；minavailable适合法定人数服务，maxunavailable适合弹性场景；单副本配pdb会导致drain卡住。
PodDisruptionBudget（PDB）不是“开了就高可用”，而是要在自愿驱逐场景下守住服务底线的精准约束。它不防节点宕机、OOM 或误删，只拦 kubectl drain、集群缩容、滚动维护这类你主动发起的操作。配对合理、配合探针和容忍度，才能真正起效。
明确 PDB 的适用边界
PDB 只响应自愿中断，比如：
-
kubectl drain node-1排空节点 - Cluster Autoscaler 缩容空闲节点
- 节点原地升级或打补丁
它对以下情况完全无效：
- 节点突然失联、硬件故障、内核 panic
- Pod 因内存超限被 OOMKilled
- 手动执行
kubectl delete pod - 污点触发的自动驱逐（除非配了对应容忍）
所以单靠 PDB 不能解决高可用，必须和副本数、反亲和性、就绪探针一起用。
选对参数：minAvailable 还是 maxUnavailable？
二者互斥，按业务习惯选其一：
Kubernetes Skills
下载
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
-
minAvailable：适合有法定人数要求的服务，比如 etcd（至少 3 个存活）、ZooKeeper。写死数字或百分比，如
minAvailable: 2或minAvailable: "75%" -
maxUnavailable：更适合弹性伸缩场景，尤其用了 HPA 的应用。例如
maxUnavailable: 1表示无论副本扩到 5 还是缩到 3，每次最多只允许 1 个不可用；maxUnavailable: "20%"更灵活
⚠️ 避免给单副本 Deployment 配 PDB——一旦设了 minAvailable: 1，kubectl drain 就永远卡住，因为没地方腾挪。
精准关联 + 必要协同
PDB 生效依赖三个关键动作：
-
selector 必须严格匹配 Pod 标签：和 Deployment/StatefulSet 中
spec.template.metadata.labels完全一致，否则 PDB 形同虚设 - 就绪探针（readinessProbe）必须启用且合理：探测失败后 Pod 自动从 Service Endpoint 移除，避免流量打到半死状态
-
关键 Pod 加长容忍时间：比如网关类 Pod，配置
tolerationSeconds: 300，防止节点短暂 NotReady 就被驱逐
别把 livenessProbe 设得太激进——频繁重启可能让 PDB 统计误判，导致驱逐被意外阻塞。
验证是否真生效
配完别只看 YAML 是否创建成功，要实测：
- 查状态：
kubectl get pdb -n your-ns看MIN AVAILABLE和CURRENT HEALTHY是否对得上 - 模拟排空：
kubectl drain node-x --dry-run=client -v=6，观察日志里是否出现disruption budget not satisfied提示 - 监控指标：
policy_pod_disruption_budget_status_conditions{condition="DisruptionsAllowed"} == 0是危险信号，需立即排查
不复杂但容易忽略。
