1.为什么要使用弹性扩缩容的概念
弹性伸缩是根据应用程序的自身承载力以及用户的业务需求，自动的调整应用程序的数量，做到随时满足的需求，通过弹性伸缩功能，可以通过定时、周期或者监控策略，当业务量高并发时，自动完成应用程序副本数的动态增加或者减少，保证业务系统的平稳运行。
往往一些电商平台在618或者双十一的时候会做很多的活动，这一天也是全年并发量最高的一天，如果由于资源紧张、工作负载压力大，就很有可能出现宕机的情况，此时就需要引入弹性扩缩容机制，自动实现副本数的动态增加或者减少。
在K8S集群中，无需编写脚本、无需进行大量的配置，就可以实现应用程序的弹性伸缩。
K8S弹性伸缩的对象针对两种：
-
Node节点层面
- 监测整个集群的负载能力，当资源到达一定点位时，触发扩容或者缩容的手段，保证集群平稳运行。
-
Pod层面
- 应用程序都是以Pod的形式部署和运行的，在部署应用程序时会写死Pod的副本数量，当高并发时，设置的Pod数量不一定可以满足业务场景，如果集群中有大量的应用程序，手动添加或者缩减Pod的数量，效率是很低的，这个时候就需要对Pod资源进行弹性伸缩，当高并发时，可以及时扩展Pod副本数。
2.K8S集群中弹性伸缩方案
2.1.HAP
HPA可以利用Metrics监控指标，例如CPU使用率、磁盘或者自定义的监控指标，通过这些指标来自动的扩容或缩容Pod的副本数量，当系统负载增加时，HPA会自动为Pod添加适量的数量，提高系统的稳定性。
HPA分为两个版本：HPA V1版本、HPA V2版本。
HPA V1版本：
V1版本只能根据CPU使用率来进行自动的扩容和缩容，较为局限性。
不是所有的应用程序都可以依靠CPU指标或者内存指标，作为业务高峰期的一个判断依据，对于大多数WEB应用程序来说，基于每秒的请求连接数才是弹性伸缩最为有效的依据，在做弹性伸缩时，千万不要局限于CPU和内存的监控数据，往往更有效的就是请求数的多与少。
HPA V2版本：
V2版本与V1版本最大的不同支之处在于，即可以基于CPU、内存作为判断依据，也可以自定义一些指标作为扩缩容的依据，例如基于每秒的请求数量作为判断条件。
HPA如何获取监控指标？可以在K8S集群中安装metrics-server指标采集器，通过metrics-server采集的监控数据进行弹性伸缩。、
HPA默认情况下，每隔30秒会检测一次指标，只要指标达到了HPA设置的阈值，则会计算出预期设置的工作负载副本数量，进行扩缩容操作，同时为了避免过于频繁的扩缩容，默认在5分钟内没有扩缩容的情况下，才会触发扩缩容操作，因为可能高并发只是一瞬间，立刻就下来了，频繁扩缩容对于集群的性能是有影响的。
在5分钟内，如果有大量的并发也会会持续扩容的，但是如果五分钟内有扩容的操作，就不会进行缩容，只有5分钟内都没有扩容时，才会进行缩容。
HPA本身的算法属于保守派，如果突发的流量高并发场景，5分钟内可能就已经宕机了，HPA因为无法扩缩容了。
2.2.KPA
KPA弹性伸缩是基于请求数对Pod自动扩缩容，KPA无法针对CPU进行扩缩容。
KPA可以根据请求数量实现自动扩缩容，也可以针对扩缩容边界实现自动扩缩容。
扩缩容边界指的是应用程序提供服务的最大和最小Pod数量。
KPA相比于HPA，最重要的就是流量突发时会进行扩缩容，可以与HPA同时使用。
2.3.VPA
VPA是基于Pod的资源使用情况自动为集群设置资源占用的限制，从而让Pod调度在满足资源的最佳节点上。
例如一开始Pod设置的资源配额为1G内存，当触发弹性伸缩后，会根据扩容或者缩容，自动跳转Pod的资源配额值，扩容时加大资源配额，缩容时缩减资源配额，从而让Pod调度在有足够资源的最佳Node节点上。
VPA在调整Pod的资源配额时，会保持原有Pod副本的资源配额值，不会去调整。
3.HPA弹性伸缩工作原理
HPA的全称是Horizontal Pod Autoscaler，HPA可以基于CPU、内存的使用率对Pod控制器中的Pod数量进行自动的扩缩容，在HPA V2版本中也可以基于自定义的指标进行自动扩缩容。
对于Daemonset、Statefulset这两种Pod控制器，HPA不适合做弹性伸缩。
HPA控制器会周期性的获取Pod的平均资源利用率，并与设定的阈值进行比较，然后调整Pod的副本数量。
HPA是根据指标来进行自动扩缩容的，目前HPA有两个版本V1和V2beta版。
HPA的API有三种不同的版本，通过以下命令可以查询。
[root@k8s-master ~]# kubectl api-versions | grep autoscal
autoscaling/v1
autoscaling/v2beta1
autoscaling/v2beta2
- **autoscaling/v1：**只支持基于CPU指标的弹性伸缩。
- **autoscaling/v2beta1：**支持CPU、内存、自定义指标的弹性伸缩。
- **autoscaling/v2beta2：**支持CPU、内存、自定义指标以及额外指标的弹性伸缩，属于测试版。
HPA弹性伸缩的监控指标是通过Metrics server获取的，Metrics server会采集所有Node节点以及集群资源的监控指标。
4.HPA的扩容原理和流程
1）扩缩容原理
HPA的实现可以理解成一个控制循环，在kube-controller-manager组件中通过–horizontal-pod-autoscaler-syncperiod参数来指定循环检测的周期，默认为15秒，在每一个周期内，kube-controller-manager组件会根据每个HPA设置的监控指标类型，从Metrics server中获取具体的资源利用率。
然后通过现有Pod的CPU使用率的平均值（从metrics-server中获取）与在HPA中设定的上限阈值进行比较，最后进行扩缩容。
在扩缩容时，需要遵循一个规则，最小的Pod数不能超过原有设定的Pod数，最大的Pod数不能超过在HPA中设置的最大限制。
计算扩容后 Pod 的个数：sum(最近一分钟内某个 Pod 的 CPU 使用率的平均值)/CPU 使用上限的整数+1
2）扩缩容流程
1、创建HPA控制器，设置CPU使用率的阈值，设置Pod伸缩副本数的最大最小值，当超过这个阈值时触发弹性伸缩机制。
2、HPA通过metrics-server获取每个Pod最近一分钟的CPU使用率，计算出平均值。
3、根据这个平均值与HPA中设定的阈值进行比较。
4、计算出要调整的副本个数。