节点资源不足时的Kubernetes节点扩展

问题描述

从文档中可以清楚地看到，每一个Pod处于Pending状态时，是因为没有节点具有足够的可用资源来满足Pod的资源请求-群集自动伸缩程序将在Pod创建后的30秒内创建另一个节点（大小的簇）。

但是，请考虑一个节点被打包的情况。假设该节点有2个CPU内核，并且包含4个Pod，它们定义了0.5个CPU请求和1.0个CPU限制。 突然有负载，并且所有4个Pod突然请求该节点无法提供的额外0.5 CPU，因为它的所有CPU已被4个正在运行的Pod占用。

在这种情况下，我希望Kubernetes通过运行无法提供服务的Pod来“了解”有待处理资源请求，并将这些Pod“移动”（销毁并创建）到另一个可以尊重其请求的节点上他们当前正在使用的资源）。如果不存在这样的节点，我希望Kubernetes创建一个额外的节点，然后将吊舱移到那里。

但是，我看不到这种情况。我看到Pod在同一节点上运行（我猜该节点可能被称为超额配置），而不管资源请求是否受到尊重，从而导致性能下降。

我的问题是，除了将pod资源请求和限制之间的比率设置为1：1（其中pod无法请求的资源比最初分配的资源更多）之外，是否可以通过任何方式避免这种行为。显然，我会避免将请求和限制设置为相同，以避免配置不足并支付超出我所需的费用。

解决方法

重要的是要认识到PodSpec中的CPU request与进程尝试使用的cpu数量之间的区别。 Kubernetes设置和集群自动缩放完全基于PodSpec中的request。实际使用与这些决定无关。

在您描述的情况下，Pod仍仅请求0.5 CPU-该字段是不可变的。现在，该进程正在尝试使用1个CPU-但这没有解决。

高于请求的CPU限制允许尽最大努力使用该容量，但是正如您所看到的，这不能保证。

在这种情况下，听起来您可能想同时使用Horizo​​ntal Pod Autoscaler和集群自动缩放器。在负载增加的情况下（例如Pod开始使用CPU request的80％以上），HPA将增加服务Pod的数量，以处理需求。如果那时这些Pod都无处可容纳，则群集自动缩放器将置备更多节点。这样，您的Pod仍然可以用尽请求值，并且只有当它们开始接近请求值时，才可以配置更多的节点，因此您不会预先超额配置资源。