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

前言

在上一篇文章 Kubernetes 弹性伸缩全场景解析 （一）：概念延伸与组件布局中，我们介绍了在 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%，判断还需要扩容两个容器；