如何使用K8S HPA和自动分频器，当Pods通常需要较低的CPU，但需要周期性的缩放时

Question

我正在尝试确定一个与K8S一起使用的可靠设置，以便使用HPA和autoscaler来扩展我的一个部署。我希望将超额承诺的资源减少到最低限度，但允许它根据需要扩大规模。

我有一个管理REST服务的部署。大多数情况下，该服务的使用率将非常低(0M-5MCPU)。但在一天或一周内，它的使用率会上升到5-10个CPU(5000米-10000米)的水平。

我在配置它时的第一个步骤是：

• 部署:1个副本

"resources": {
   "requests": {
     "cpu": 0.05
   },
   "limits": {
      "cpu": 1.0
   }
}

• HPA：

"spec": {
   "maxReplicas": 25,
   "metrics": [
      {
         "resource": {
         "name": "cpu",
         "target": {
            "averageValue": 0.75,
            "type": "AverageValue"
         }
         },
         "type": "Resource"
      }
   ],
   "minReplicas": 1,
   ...
}

这是在运行自动分频器的AWS EKS集群上运行的。所有实例都有两个CPU。目标是，随着CPU使用量的增加，HPA将分配一个不可调度的新pod，然后自动分配器将分配一个新的节点。当我在服务上添加负载时，第一个吊舱的CPU使用量在最大时达到了大约90%-95%。

我遇到了两个相关的问题：

1. 小请求大小

通过使用如此小的请求值(cpu: 0.05)，即使在当前节点处于高负载下，新请求的豆荚也可以很容易地调度到当前节点上。因此，自动分词器永远找不到不能调度的荚，也不会分配新的节点。我可以增加小的请求大小和超额提交，但这意味着在大多数情况下，当没有负载时，我将浪费我不需要的资源。

1. 平均CPU随分配的荚数增加而减少。

因为豆荚都是在同一个节点上分配的，所以一旦分配了一个新的荚，它就开始共享该节点的可用的两个CPU。这反过来减少了吊舱使用的CPU数量，从而使平均值低于75%的目标。

(例:3个吊舱，2个CPU ==>最大平均每荚使用CPU 66% )

我在这里寻求关于我应该如何思考这个问题的指导。我想我错过了一些简单的东西。

我目前的想法是，我正在寻找的是一种方法，使Pod资源请求值在更重的负载下增加，然后在系统不需要时减少。这将指向我使用类似于VPA的东西，但我所读到的一切都表明，同时使用HPA和VPA会导致非常糟糕的事情。

我认为将请求从0.05增加到0.20可能会让我处理扩展的问题。但这反过来会浪费大量的资源，如果调度程序在现有的吊舱上找到空间，可能会遇到问题。我的例子是关于一个服务，但是在生产部署中还有更多的服务。我不想让节点空着被提交的资源，但不想使用。

在这里，什么是最好的前进之路？

Answer 1

听起来，您需要一个考虑实际CPU利用率的计划程序。这一点还没有得到支持。

似乎有这样一个特性:使用KEP - Trimaran:真正的负荷感知调度的TargetLoadPackin插件。也见用于实际平均负载和空闲内存的新调度器优先级。

同时，如果CPU限制为1 Core，且节点在较高的CPU利用率下自动调整，则如果节点的容量远远大于CPU限制，则应该工作。例如，尝试使用具有4个核心或更多，并且可能稍微大一点的Pod CPU请求的节点？