Kubernetes Autoscaler：可以缩​​减规模时，部署是否不会停机？

问题描述

在一个项目中，我从Kubernetes启用了集群自动缩放器功能。

根据文档How does scale down work，我了解到，当给定时间使用某个节点的时间少于其容量的50％时，该节点将连同其所有吊舱一起被移除，并将被复制如果需要，可以在另一个节点中。

但是会发生以下问题：如果与特定部署相关的所有pod都包含在要删除的节点中，该怎么办？这意味着用户可能会因部署此应用程序而停机。

是否有一种方法可以避免在有仅包含在该节点上运行的Pod的部署中按比例缩小删除一个节点？

我已经检查了文档，一种可能（但不是很好）的解决方案是在包含应用程序here的所有Pod中添加注释，但这显然不会以最佳方式缩减集群的规模。

解决方法

在同一文档中：

非空节点终止时会发生什么？如上所述，所有pod都应迁移到其他地方。群集自动缩放器通过驱逐它们并污染节点来实现此目的，因此不再将它们安排在那里。

Eviction是什么？：

吊舱的收回子资源可以被视为对吊舱本身的一种策略控制的DELETE操作。

好吧，但是如果节点上的所有吊舱同时都被搬出怎么办？ 您可以使用Pod Disruption Budget来确保最少的副本始终在工作：

什么是PDB？

PDB限制了由于自愿中断而同时减少的复制应用程序的Pod数量。

在k8s docs中，您还可以阅读：

PodDisruptionBudget具有三个字段：

标签选择器.spec.selector，指定要应用的Pod集合。此字段为必填。

.spec.minAvailable which is a description of the number of pods from that set that must still be available after the eviction，即使没有被驱逐的吊舱也是如此。 minAvailable可以是绝对数字或百分比。

.spec.maxUnavailable（在Kubernetes 1.7和更高版本中可用），它描述了该集合中逐出后可能不可用的Pod数量。它可以是绝对数字或百分比。

因此，如果您使用PDB进行部署，则不应立即将其全部删除。

但是请注意，如果节点由于其他原因（例如硬件故障）而发生故障，您仍然会遇到停机时间。如果您真的在意高可用性，请考虑使用Pod Antiaffinity来确保未将Pod安排在一个节点上。

,

您引用的同一文档具有以下内容：

集群自动缩放器与基于CPU使用率的节点自动缩放器有何不同？群集自动缩放器可确保 无论是否有CPU负载或 不。此外，它试图确保其中没有不需要的节点 集群。

基于CPU使用率（或任何基于度量标准）的群集/节点组自动缩放器 放大和缩小时都不必关心豆荚。结果，他们可能 添加一个没有任何吊舱的节点，或删除一个有一些吊舱的节点 像kube-dns这样的系统关键Pod。这些自动缩放器的用法 不鼓励使用Kubernetes。