1

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

根据文档：How does scale down work，我知道当一个节点在给定时间内使用少于其容量的 50% 时，它会连同它的所有 Pod 一起被删除，这些 Pod 将被复制到不同的如果需要，节点。

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

有没有办法避免在部署仅包含在该节点上运行的 Pod 时缩减删除节点？

我检查了文档，一个可能（但不是很好）的解决方案是在此处向所有包含应用程序的 pod 添加注释，但这显然不会以最佳方式缩小集群。

4

2 回答 2

1

在同一文档中：

当非空节点终止时会发生什么？如上所述，所有 pod 都应该迁移到其他地方。Cluster Autoscaler 通过驱逐它们并污染节点来做到这一点，因此它们不会再次被安排在那里。

什么是驱逐？：

Pod 的逐出子资源可以被认为是对 Pod 本身的一种策略控制的 DELETE 操作。

好的，但是如果节点上的所有 pod 同时被驱逐怎么办？您可以使用 Pod Disruption Budget 来确保最小副本始终有效：

什么是 PDB？：

PDB 会限制因自愿中断而同时停机的复制应用程序的 Pod 数量。

在k8s 文档中，您还可以阅读：

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，即使没有被驱逐的 pod。minAvailable 可以是绝对数或百分比。

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

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

但是请注意，如果节点由于其他原因（例如硬件故障）而失败，您仍然会遇到停机时间。如果您真的关心高可用性，请考虑使用 pod 反亲和性来确保 pod 不会全部安排在一个节点上。

于 2020-08-17T09:25:36.407 回答
0

您提到的同一文件具有以下内容：

Cluster Autoscaler 与基于 CPU 使用的节点自动扩缩器有何不同？Cluster Autoscaler 确保集群中的所有 pod 都有运行的地方，无论是否有任何 CPU 负载。此外，它试图确保集群中没有不需要的节点。

基于 CPU 使用（或任何基于指标）的集群/节点组自动扩缩器在扩展和缩减时不关心 Pod。因此，他们可能会添加一个没有任何 pod 的节点，或者删除一个上面有一些系统关键 pod 的节点，例如 kube-dns。不鼓励将这些自动缩放器与 Kubernetes 一起使用。

于 2020-08-15T02:32:07.867 回答