文章目录
- Kubernetes PDB（Pod Disruption Budget）详解
- 一、什么是 PDB？
- 二、什么是“自愿中断”？
- 1. 自愿中断（PDB 可控制）
- 2. 非自愿中断（PDB 无法控制）
- 三、PDB 的核心字段
- 1. `minAvailable`
- 2. `maxUnavailable`
- 四、PDB 工作原理
- 五、PDB 示例
- 示例：保证至少 2 个 Pod 可用
- 示例：最多允许 1 个 Pod 不可用
- 六、典型使用场景
- 1. 高可用服务（推荐）
- 2. Stateful 应用（谨慎使用）
- 3. 单副本应用（不建议设置 PDB）
- 七、PDB 与 HPA / Deployment 的关系
- 与 Deployment
- 与 HPA（Horizontal Pod Autoscaler）
- 八、常见坑与注意事项
- 1. PDB 设置过严
- 2. 副本数不足
- 3. 忽略 Pod Ready 状态
- 4. 与滚动更新冲突
- 九、最佳实践
- ✅ 推荐策略
- ❌ 避免做法
- 十、总结
Kubernetes PDB（Pod Disruption Budget）详解
在生产环境中运行 Kubernetes（K8s）集群时，服务的高可用性至关重要。我们常常会遇到节点维护、集群升级、自动扩缩容等场景，这些操作可能导致 Pod 被驱逐（Eviction）。如果没有合理控制，可能会引发服务中断。
为了解决这个问题，Kubernetes 提供了一个重要机制：PDB（Pod Disruption Budget）。
一、什么是 PDB？
Pod Disruption Budget（PDB）是 Kubernetes 中用于限制“自愿中断”（Voluntary Disruption）的资源对象。
它的核心作用是：
在集群发生维护或调度操作时，确保系统中始终有足够数量的 Pod 保持可用。
二、什么是“自愿中断”？
PDB 只对“自愿中断”生效，而不控制“非自愿中断”。
1. 自愿中断（PDB 可控制）
由人为或系统触发的操作，例如：
- 节点维护（
kubectl drain） - 集群升级
- 自动扩缩容（Cluster Autoscaler）
- Pod 重调度
2. 非自愿中断（PDB 无法控制）
不可预测的故障，例如：
- 节点宕机
- 容器崩溃
- 网络故障
👉 关键点：PDB 不是高可用的万能保障，它只是“优雅中断”的控制器。
三、PDB 的核心字段
PDB 主要通过两个字段来定义可用性约束：
1.minAvailable
表示至少要有多少个 Pod 保持可用
minAvailable:2👉 含义：无论如何，至少 2 个 Pod 必须在运行
2.maxUnavailable
表示最多允许多少个 Pod 不可用
maxUnavailable:1👉 含义：最多允许 1 个 Pod 被驱逐
⚠️ 注意：
minAvailable和maxUnavailable不能同时设置- 支持整数或百分比（如
"50%"）
四、PDB 工作原理
当执行如下操作时：
kubectl drain<node>Kubernetes 会：
- 尝试驱逐该节点上的 Pod
- 查询该 Pod 是否受 PDB 约束
- 判断驱逐是否违反 PDB
如果违反：
👉驱逐会被阻止（Eviction 被拒绝）
五、PDB 示例
示例：保证至少 2 个 Pod 可用
apiVersion:policy/v1kind:PodDisruptionBudgetmetadata:name:my-app-pdbspec:minAvailable:2selector:matchLabels:app:my-app示例：最多允许 1 个 Pod 不可用
apiVersion:policy/v1kind:PodDisruptionBudgetmetadata:name:my-app-pdbspec:maxUnavailable:1selector:matchLabels:app:my-app六、典型使用场景
1. 高可用服务（推荐）
例如：
- Web 服务
- API 服务
- 微服务
👉 防止同时驱逐过多 Pod，导致服务不可用
2. Stateful 应用（谨慎使用）
例如：
- 数据库（MySQL / PostgreSQL）
- Kafka / ZooKeeper
👉 通常需要更严格的 PDB 策略（甚至 0 disruption）
3. 单副本应用（不建议设置 PDB）
如果 Deployment 只有 1 个 Pod：
- 设置 PDB 会导致节点无法 drain
- 集群维护可能被“卡死”
七、PDB 与 HPA / Deployment 的关系
与 Deployment
- Deployment 控制 Pod 数量
- PDB 控制 Pod能否被驱逐
👉 两者是互补关系
与 HPA（Horizontal Pod Autoscaler）
- HPA 扩缩容时不会被 PDB 阻止
- 但缩容过程中仍需满足 PDB 约束
八、常见坑与注意事项
1. PDB 设置过严
minAvailable:100%👉 会导致：
- 节点无法维护
- 滚动升级卡住
2. 副本数不足
replicas:2minAvailable:2👉 任何驱逐都会失败
3. 忽略 Pod Ready 状态
PDB 只计算Ready 状态的 Pod
👉 如果 Pod 不健康：
- 实际可驱逐空间会更小
4. 与滚动更新冲突
Deployment 滚动更新时：
- 也可能触发 PDB 限制
- 导致更新速度变慢
九、最佳实践
✅ 推荐策略
- 至少 2~3 个副本 + 合理 PDB
- 使用
maxUnavailable: 1（简单安全） - 对关键服务强制设置 PDB
❌ 避免做法
- 单副本应用设置 PDB
- 使用极端值（100% / 0）
- 忽略 Ready 状态
十、总结
PDB 是 Kubernetes 中保障服务稳定性的重要机制：
👉 它解决的问题是：
- “在维护过程中，系统还能不能正常服务？”
👉 核心价值：
- 控制驱逐节奏
- 防止服务雪崩
- 提升系统可用性
但要记住：
PDB ≠ 高可用本身，它只是高可用体系中的一环。
