Kubernetes PDB计入中断预算，不等于它能阻止每次中断

集群资料中写了“已配置PDB”，是否就能说明应用不会出现超过预期的中断？要回答这个问题，先看PodDisruptionBudget约束的范围。一个预算对象存在，并不等于所有可能造成Pod不可用的机制都受它控制。

Kubernetes官方Disruptions文档把中断分为自愿和非自愿两类。PodDisruptionBudget一节说明，它用于限制副本化应用因自愿中断而同时不可用的Pod数量，并将这一机制与Eviction API联系起来。这里描述的是特定机制的预算约束，而非整个应用可用性的统一保证。

同节明确写出，PDB不能防止非自愿中断，但这些中断仍会计入预算。因而“计入预算”和“事先被预算阻止”不能视为同义词。某项事件影响了预算，并不意味着该事件发生前一定经过PDB允许。

应用滚动升级是另一个需要单列的范围。文档说明，升级造成的Pod删除或不可用会计入预算，但Deployment、StatefulSet等工作负载资源进行滚动升级时，并不受PDB限制。更新期间如何处理失败，由相应工作负载的规格来配置。本文只转述这层职责划分，不给出更新参数或生产变更方案。

在评审应用交付资料时，若一个条目只写“PDB已建”，还没有回答应用更新、非自愿故障和自愿驱逐分别怎样处理。资料可以保留PDB对应对象、事件类型及相关工作负载说明，让每一项结论回到它自己的证据。无需为了把表格填满，就把未核查的其他机制一起标为已覆盖。

尤其要避免把一个运行现象直接判成PDB失效。本文没有取得任何集群事件或配置，不能判断实际中断来自哪个环节。解释现象前，应先让记录说明当时发生的是什么，以及为何认为它属于某一类中断；只给出不可用副本数，还没有确定原因。

本稿采用本次读取的官方概念文档，没有连接集群、执行驱逐、删除资源或修改预算。它要澄清的是三个不同问题：哪些变化计入预算，哪些操作受预算约束，以及整个应用是否达到目标可用性。前两项的文档说明，不能单独替代第三项的实际验证。