kubernetes hpa请求cpu和目标cpu值

Question

我正在阅读kubernetes hpa example上的示例。在此示例中，它们以：kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --expose --port=80运行。因此，该吊舱将要求200m的cpu（每个核心为0.2）。之后，他们以50％的目标CPU运行hpa：kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10。这意味着所需的毫核心为200m * 0.5 = 100m。他们进行负载测试，并承担305％的负载。根据{{​​3}}，这意味着自动缩放至：ceil（（3.05 * 200m）/ 100m）= 7个吊舱。

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

hpa scaling algorith

我们选择的目标CPU为500％（第二种选择）。对我来说，目标cpu> = 100％是一个很奇怪的概念（也许我也理解错了，因为我不太熟悉整个概念，所以请纠正我），但是与倒置（第一个选择）相比，它会降低缩放比例。

Answer 1

第一种方法是正确的。

第二个不好的原因有几个：

1. 当第一个Pod已经超载时，决定扩展集群的必要性为时已晚。如果只给一个Pod提供 100千位CPU ，但在允许采取扩展群集的决定之前，您允许这种情况使用的可用空间是可用内存的5倍。这样的系统效率不高，每个内核的平均负载约为5个，这意味着在给定的时间内服务1个进程时，还有4个进程在等待CPU时间。
2. 与缩减群集相同。 假设您的群集中的一般CPU使用量减少了400毫微米，但仍不足以删除一个副本并缩小群集。在第一种情况下，将已经删除了4个副本，并且按比例缩小了群集。

另一项非常重要的事情。在规划 Horizo​​ntal Pod Autoscaler 时，请考虑集群中可用的资源总量，以免资源不足时不会陷入困境。

示例：您有一个带有2核处理器的系统，从群集的角度来看，该系统等于可用的2000毫安。假设您决定创建以下部署：

kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=500m --expose --port=80

然后 Horizo​​ntal Pod Autoscaler ：

kubectl autoscale deployment php-apache --cpu-percent=100 --min=1 --max=5

这意味着您允许请求的资源比群集中实际可用的资源更多，因此在这种情况下将永远不会创建第5个副本。