假设我有一个Deployment，.spec.strategy.rollingUpdate.maxUnavailable字段设置了一个特定的值。然后部署一个附加到上面部署的PodDisruptionBudget，将其spec.maxUnavailable字段设置为与上面不同的值。哪一个会占上风？
Deployment
.spec.strategy.rollingUpdate.maxUnavailable
PodDisruptionBudget
spec.maxUnavailable
6rqinv9w1#
通过解释文档，它似乎取决于事件。对于滚动更新，Deployment的maxUnavailable将生效，即使PodDisruptionBudget指定了一个较小的值。但是对于驱逐，PodDisruptionBudget的maxUnavailable将占上风，即使Deployment指定了一个较小的值。文档没有明确地比较这两个设置，但是从文档的编写方式可以推断出，这些是不同事件的单独设置，它们不会相互作用。举例来说：
maxUnavailable
kubectl explain deploy.spec.strategy.rollingUpdate.maxUnavailable
kubectl explain pdb.spec.maxUnavailable
此外，这更符合Kubernetes的工作原理。部署控制器不会读取PodDisruptionBudget的字段，反之亦然。但要确定，你只需要尝试一下。
sqyvllje2#
我相信他们更新了文档，澄清了你的疑问：非自愿中断不能通过临时预算来防止，但它们确实会影响预算。由于应用程序的滚动升级而被删除或不可用的Pod确实会计入中断预算，但在进行滚动升级时，工作负载资源（如Deployment和StatefulSet）不受PDB的限制。相反，在应用程序更新期间对故障的处理在规范中为特定的工作负载资源配置注意事项：并非所有自愿中断都受到Pod中断预算的约束。例如，删除部署或Pod会绕过Pod中断预算。
bcs8qyzn3#
目前的答案为我们指出了正确的方向，但它们的组合对我来说不够明确。以下是我的理解：
node drain
相关讨论：https://github.com/kubernetes/kubernetes/issues/39824
3条答案
按热度按时间6rqinv9w1#
通过解释文档，它似乎取决于事件。
对于滚动更新，Deployment的
maxUnavailable将生效，即使PodDisruptionBudget指定了一个较小的值。但是对于驱逐，PodDisruptionBudget的
maxUnavailable将占上风，即使Deployment指定了一个较小的值。文档没有明确地比较这两个设置，但是从文档的编写方式可以推断出，这些是不同事件的单独设置，它们不会相互作用。
举例来说：
kubectl explain deploy.spec.strategy.rollingUpdate.maxUnavailable的输出kubectl explain pdb.spec.maxUnavailable的输出此外，这更符合Kubernetes的工作原理。部署控制器不会读取PodDisruptionBudget的字段，反之亦然。
但要确定，你只需要尝试一下。
sqyvllje2#
我相信他们更新了文档，澄清了你的疑问：
非自愿中断不能通过临时预算来防止，但它们确实会影响预算。
由于应用程序的滚动升级而被删除或不可用的Pod确实会计入中断预算，但在进行滚动升级时，工作负载资源（如Deployment和StatefulSet）不受PDB的限制。相反，在应用程序更新期间对故障的处理在规范中为特定的工作负载资源配置
注意事项：并非所有自愿中断都受到Pod中断预算的约束。例如，删除部署或Pod会绕过Pod中断预算。
bcs8qyzn3#
目前的答案为我们指出了正确的方向，但它们的组合对我来说不够明确。以下是我的理解：
node drain）确实使用了Eviction API。后者可能由某些托管过程调用，Azure Kubernetes Service（AKS）版本升级就是这种情况：https://learn.microsoft.com/en-us/azure/aks/upgrade-aks-cluster?tabs=azure-cli#upgrade-an-aks-cluster。PDB将在此类过程中保护您。TLDR为了回答最初的问题，在这种情况下，
.spec.strategy.rollingUpdate.maxUnavailable将“占上风”（从某种意义上说，它是唯一相关的设置，因为没有使用Eviction API，因此没有使用PDB）。相关讨论：https://github.com/kubernetes/kubernetes/issues/39824