kubernetes hpa 请求 cpu 和 objective-c pu 值

Question

我正在阅读 kubernetes hpa example 的示例.在这个例子中，它们运行:kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --expose --port=80 .所以 pod 将要求 200m 的 cpu(每个核心 0.2)。之后他们以 50% 的 objective-c pu 运行 hpa:kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10 .这意味着所需的毫核为 200m * 0.5 = 100m。他们进行了负载测试并施加了 305% 的负载。这意味着自动扩展至: ceil((3.05 * 200m)/100m) = 7 个 pod，根据:hpa scaling algorith .

这一切都很好，但我们正在尝试不同的值，我想知道这是否是一个好方法。



我们选择了 500% 的 objective-c PU(第二个选项)。对我来说，target cpu >= 100% 是一个奇怪的概念(也许我也理解错了，请纠正我，因为我对整个概念不太熟悉)，但与倒置的(第一个选项)相比，它会减慢缩放速度。

Answer 1

第一种方法是正确的。

第二个不好，有几个原因:

关于扩展集群必要性的决定为时已晚 ，当第一个 Pod 已经重载时。如果你只给 100 毫核 CPU 到一个 Pod ，但是您允许它可以使用可用资源的 5 倍的情况，然后才可以做出关于扩展集群的决定。这样的系统效率不高，每个核心的平均负载约为 5，这意味着当在给定时间内服务 1 个进程时，还有另外 4 个进程在等待 CPU 时间。

与缩小集群相同。它也不是很有效。 假设您的集群中的一般 CPU 使用率减少了 400 多个毫核，但仍然不足以删除一个副本并缩小集群。在第一种情况下，场景 4 副本已经被删除并且集群缩小了。

另一个很重要的事情 .在计划您的 时水平 Pod 自动缩放器 ，请考虑集群中可用的资源总量，这样您就不会发现自己处于资源耗尽的情况。

示例:您有一个具有 2 核处理器的系统，从集群的角度来看，这等于有 2000 个毫核可用。假设您决定创建以下部署:
kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=500m --expose --port=80
然后 水平 Pod 自动缩放器 :
kubectl autoscale deployment php-apache --cpu-percent=100 --min=1 --max=5
这意味着您允许请求的资源比集群中实际可用的资源多，因此在这种情况下，永远不会创建第 5 个副本。