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

前言

在上一篇文章中，咱们介绍了在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再进行计算。