Kubernetes PodDisruptionBudget、Horizo​​ntalPodAutoscaler 和 RollingUpdate 交互？

Posted 2023-03-04

【中文标题】Kubernetes PodDisruptionBudget、Horizo​​ntalPodAutoscaler 和 RollingUpdate 交互？

【英文标题】：Kubernetes PodDisruptionBudget, HorizontalPodAutoscaler & RollingUpdate Interaction?

【发布时间】：2019-07-21 00:17:39

【问题描述】：

如果我有以下 Kubernetes 对象：

Deployment 与 rollingUpdate.maxUnavailable 设置为 1。 PodDisruptionBudget 与 maxUnavailable 设置为 1。 HorizontalPodAutoscaler 设置为允许自动缩放。 已启用集群自动缩放。

如果集群负载不足并且正在扩展，会发生什么：

在滚动更新期间？由于扩大规模而添加的新Pod 是否使用新版本的Pod？ 何时需要重新启动或更换节点？ PodDisruptionBudget 是否完全停止重新启动？ HorizontalPodAutoscaler 是否会在关闭另一个节点之前增加节点数量？ 当Pod 关联性设置为避免将来自同一Deployment 的两个Pod 放置在同一节点上时。

【参考方案1】：

如documentation:

由于滚动升级应用程序而被删除或不可用的 Pod 会计入中断预算，但控制器（如部署和状态集）在滚动升级时不受 PDB 的限制——应用程序期间的故障处理更新在控制器规范中配置。

所以它部分取决于控制器的配置和实现。我相信自动缩放器添加的新 Pod 将使用新版本的 Pod，因为那是当时部署定义中存在的版本。

这取决于您执行节点重启的方式。如果你只是切断电源，什么都做不了;）如果你在关闭节点之前执行正确的drain，那么PodDisruptionBudget将被考虑在内，并且排水程序不会违反它。 Eviction API 遵守中断预算，但可能会违反手动删除 pod 等低级别操作。这更像是一些 API 尊重的建议，而不是整个 Kubernetes 强制执行的强制限制。

根据official documentation，如果将亲和性设置为“软”，则 pod 将被安排在同一个节点上。如果它是“困难的”，那么部署将被卡住，无法安排所需数量的 pod。滚动更新仍然是可能的，但 HPA 将无法再扩大 pod 池。