Kubernetes弹性伸缩全场景解读(二) - HPA的原理与演进

2018/11/30 14:25
阅读数 231

前言

在上一篇文章中,我们介绍了在Kubernetes在处理弹性伸缩时的设计理念以及相关组件的布局,在今天这篇文章中,会为大家介绍在Kubernetes中弹性伸缩最常用的组件HPA(Horizontal Pod Autoscaler)。HPA是通过计算Pod的实际工作负载进行重新容量规划的组件,在资源池符合满足条件的前提下,HPA可以很好的实现弹性伸缩的模型。HPA到目前为止,已经演进了三个大的版本,在本文中会为大家详细解析HPA底层的原理以及在Kubernetes中弹性伸缩概念的演变历程。

HPA基本原理

HPA是根据实际工作负载水平伸缩容器数目的组件,从中可以提炼出两个非常重要的关键字:负载数目。我们可以用一个非常简单的数学公式进行归纳:

bacc0483353082a419e4d86a069b906a.png

下面举一个实际例子进行上述公式的阐述,假设存在一个叫ADeployment,包含3个Pod,每个副本的Request值是1核,当前3个Pod的CPU利用率分别是60%、70%与80%,此时我们设置HPA阈值为50%,最小副本为3,最大副本为10。接下来我们将上述的数据带入公式中。

  • 总的Pod的利用率是60%+70%+80% = 210%。
  • 当前的Target是3。
  • 算式的结果是70%,大于阈值的50%阈值,因此当前的Target数目过小,需要进行扩容。
  • 重新设置Target值为5,此时算式的结果为42%低于50%,判断还需要扩容两个容器。
  • 此时HPA设置Replicas为5,进行Pod的水平扩容。

经过上面的推演,可以协助开发者快速理解HPA最核心的原理,不过上面的推演结果和实际情况下是有所出入的,如果开发者进行试验的话,会发现Replicas最终的结果是6而不是5。这是由于HPA中一些细节的处理导致的,主要包含如下三个主要的方面:

  1. 噪声处理

通过上面的公式可以发现,Target的数目很大程度上会影响最终的结果,而在Kubernetes中,无论是变更或者升级,都更倾向于使用Recreate而不是Restart的方式进行处理。这就导致了在Deployment的生命周期中,可能会出现某一个时间,Target会由于计算了Starting或者Stopping的的Pod而变得很大。这就会给HPA的计算带来非常大的噪声,在HPA Controller的计算中,如果发现当前的对象存在Starting或者StoppingPod会直接跳过当前的计算周期,等待状态都变为Running再进行计算。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部