1. PDB 基础概念：PodDisruptionBudget 定义、作用与集群升级的关系
1.1 什么是 PodDisruptionBudget？
PodDisruptionBudget（PDB） 是 Kubernetes 中用于保障应用在自愿中断（Voluntary Disruption）场景下可用性的一种资源对象。它定义了一个 Pod 集合在任意时刻最多可以有多少个 Pod 同时不可用，或者最少需要保持多少个 Pod 处于可用状态。
核心定义：PDB 是集群管理员在允许节点维护、集群升级、资源调度等操作时，确保关键业务不因 Pod 被驱逐而中断的“安全护栏”。
1.2 PDB 的作用与价值
| 作用维度 | 具体说明 | 典型场景 |
|---|---|---|
| 可用性保障 | 确保应用在自愿中断期间维持最低可用副本数 | 集群升级、节点池滚动 |
| 中断控制 | 限制同时被驱逐的 Pod 数量，避免雪崩 | 节点维护、资源缩容 |
| 优先级管理 | 区分关键业务与非关键业务的中断容忍度 | 核心服务 vs 日志采集 |
| 合规与 SLO | 满足服务等级目标（SLO）对中断窗口的要求 | 金融、实时交易系统 |
1.3 PDB 与集群升级的核心关系
集群升级（如 kubelet 版本更新、节点操作系统补丁）是 Kubernetes 生命周期中最常见的自愿中断场景。PDB 在此过程中扮演以下关键角色：
- 升级速率控制：PDB 决定了节点升级的并行度——每次只能驱逐满足 PDB 约束数量的 Pod，从而控制升级节奏。
- 业务连续性保障：在节点排水（drain）过程中，kube-controller-manager 会检查 PDB，确保驱逐操作不会导致服务降级。
- 升级失败回滚保护：如果 PDB 约束导致升级卡住，系统可以提前识别风险，避免盲目推进。
- 资源配额校准依据：PDB 的 minAvailable / maxUnavailable 值直接反映业务对中断的容忍度，是资源配额规划的重要输入。
关键认知：没有 PDB 的集群升级，相当于在高速公路上拆除所有限速标志——升级速度可能很快，但一旦发生问题，恢复成本极高。
1.4 PDB 工作流程示意图
1.5 PDB 定义示例
以下是一个典型的 PDB 资源定义，用于保障某 Web 服务在集群升级期间至少保持 2 个副本可用：
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: web-pdb
namespace: production
spec:
minAvailable: 2
selector:
matchLabels:
app: web-server
tier: frontend
常见误区：PDB 只约束自愿中断（如 drain、cordon、节点升级），对非自愿中断（如节点宕机、磁盘故障）无效。非自愿中断需要依赖 ReplicaSet、多副本部署等机制来保障。
1.6 PDB 与集群升级的量化关系
| 升级场景 | PDB 配置 | 升级并行度 | 业务影响 |
|---|---|---|---|
| 无 PDB | 未配置 | 无限制 | 高——可能瞬间丢失所有副本 |
| 宽松 PDB | maxUnavailable: 50% | 较高 | 中——部分流量损失 |
| 严格 PDB | minAvailable: 80% | 较低 | 低——几乎无感知 |
| 极严格 PDB | minAvailable: 100% | 极低（可能卡死） | 无——但升级可能无法完成 |
最佳实践：生产环境建议为所有 Deployment/StatefulSet 配置 PDB，minAvailable 推荐设置为
replicas - 1 或 ceil(replicas * 0.75)，在升级速度与业务可用性之间取得平衡。