如何解决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。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。