Autopilot: workload autoscaling at Google论文描述的requests预测算法

原创 吴就业 150 0 2024-04-01

本文为博主原创文章,未经博主允许不得转载。

本文链接:https://wujiuye.com/article/3e23ccd31c8f4abeae717305a04672da

作者:吴就业
链接:https://wujiuye.com/article/3e23ccd31c8f4abeae717305a04672da
来源:吴就业的网络日记
本文为博主原创文章,未经博主允许不得转载。

论文:Autopilot: workload autoscaling at Google

本篇简单描述此论文中描述的资源request预测算法,不需要理解论文中那复杂的数学公式。

负载分布直方图

负载分布直方图

我们以cpu资源为例。直方图的横坐标是毫核,按5%的等比例,划分为400个桶,纵坐标是数量。然后取一段时间的cpu使用量指标,比如原算法中举例取5分钟,获取这5分钟所有采集的cpu使用指标,如果指标是每秒上报一次,那么5分钟就有300个指标,然后将这300个指标根据指标的值放入相对应的桶中,每个桶每放入一个指标那么数量+1。直方图是后续计算的基础。

假如我们需要拿12小时的指标数据来预测,一个直方图使用5分钟的数据,那么12小时就对应生成144张直方图。

论文中还引入了衰退系数,衰退系数其实是给直方图加权重,离当前时间越近的指标越有参考价值,所以权重越高,那么对应的直方图的衰退系数越大。

论文中取5分钟指标,按5%等比例(1.05的n次方)划分桶,以及分成400个桶,取多少个小时的数据分成多少个直方图,这些都不是固定的,都是可以调的。

为什么是5%以及400个桶?为什么是5%不清楚,但400个桶是为了覆盖边界值。因为1.05的400次方是299033351.24884427,对于cpu,299033351.24884427约为299033核,对于内存,299033351.24884427约为292024GB。

这个数字对我们来说太大了,假如我们限定单个Pod最大可用的cpu为8核、内存为16G,那么我们可以调整桶的数量为200个。1.05的200次方是17292.58081516013,对于cpu,17292.58081516013约为17核,对于内存,17292.58081516013约为16GB。刚好可以覆盖边界。

算法计算解释

我们最终需要算出S(max)、S(avg)、S(xxline)。S(px)如S(p98)、S(p95)、S(p90)、S(p60)。

对于CPU,如果是一些批处理任务,我们就使用S(avg)作为cpu的request值;如果是在线业务,则根据对于延迟的容忍程度,选择S(95line)或者S(90line)值。

对于内存,一般的任务可以根据对于OOM的忍受程度,选择S(98line)或者S(max),如果是批处理的任务,可以选择S(60line)和1/2*S(max)之间的最大值。

在选定对应的值后,可以再增加10%-15%的安全边界(推荐值越大,应该选择更小的安全边界)。

算法参数微调

#云原生

声明:公众号、CSDN、掘金的曾用名:“Java艺术”,因此您可能看到一些早期的文章的图片有“Java艺术”的水印。

文章推荐

Kubebuilder控制器配置Owns然而监听到事件却不触发Reconcile方法

我们在CreateFunc、DeleteFunc、UpdateFunc方法中添加日记,发现这些方法被调用了,但却没有触发控制器的Reconcile方法执行。

满足Autoscaler触发自定扩容Node的条件是什么?

我们使用自定义的调度器来调度pod,有自定义的Filter插件。Autoscaler在执行扩容之前,会调用Filter插件,尝试是不是真的没有node满足调度这个pod再去扩容。而默认情况下,Autoscaler拿的是默认的Filter插件,拿不到我们自定义的Filter插件,所以没有走我们的Filter逻辑,所以不会扩容。

如何实现一个简单的K8s apiserver

apiserver是k8s的另一种扩展机制,相比CRD,它更为灵活。本篇以实战为主,介绍如何实现一个简单的apiserver。

K8s Pod可观测cpu使用率转cpu使用量

前面《如何获取Pod的CPU和内存指标,使用Grafana Agent收集指标,上传到Prometheus》这篇介绍的指标获取只拿到了cpu使用率,怎么转成cpu使用量呢?

云原生专栏第一阶段完结,第二阶段开始

由于方向的错误,我们第一阶段开发的云原生PaaS平台这个项目也迎来了终结。但我们换了个方向继续做云原生PaaS平台。

使用Grafana Agent收集Pod的cpu和内存指标,以及标准输出日志的完整案例

通常指标和日志收集这两者是一起的,可观测即离不开指标,也离不开日记。当两者都需要的时候,就没必要部署两个DaemonSet了。本篇将两者结合成一个完整的案例,大家可以直接拿去部署使用。