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

2019独角兽企业重金招聘Python工程师标准>>>

前言

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

HPA基本原理

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

下面举一个实际例子进行上述公式的阐述，假设存在一个叫A的Deployment，包含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或者Stopping的Pod会直接跳过当前的计算周期，等待状态都变为Running再进行计算。

转载于:https://my.oschina.net/u/3611008/blog/2964026