《Kubernetes知识篇：Kubernetes资源自动伸缩的三种方法》

文章目录 2.3、VPA 2.4、KPA 三、部署-服务四、HPA实现pod自动扩缩容 五、VPA实现pod自动扩缩容 六、KPA实现pod自动扩缩容总结：整理不易，如果对你有帮助，可否点赞关注一下？

一、背景

弹性伸缩是根据用户的业务需求和策略，自动“调整”其“弹性资源”的管理服务。通过弹性伸缩功能，用户可设置定时、周期或监控策略，恰到好处地增加或减少“弹性资源”，并完成实例配置，保证业务平稳健康运行。

二、K8S中自动伸缩的方案

在的生态中，在多个维度、多个层次提供了不同的组件来满足不同的伸缩场景。

1、CA（ ）：Node级别自动扩/缩容-组件

2、HPA（ Pod ）：Pod个数自动扩/缩容

3、VPA（ Pod ）：Pod配置自动扩/缩容，主要是CPU、内存,addon-组件

2.1、CA 2.2、HPA 2.2.1、简介

scale命令可以来实现Pod的扩缩容功能，但是需要手动操作，面对线上环境的各种复杂情况，我们需要能够做到自动化的去感知业务，来自动进行扩缩容。为此，提供了这样的一个资源对象： Pod （Pod水平自动伸缩），简称HPA，HPA通过监控分析一些控制器控制的所有Pod的负载变化情况来确定是否需要调整Pod的副本数量。

1、Pod水平自动扩缩（ Pod ） 可以基于CPU利用率自动扩缩r、、 和中的Pod数量。 除了CPU利用率，也可以基于其他应程序提供的自定义度量指标来执行自动扩缩。 Pod自动扩缩不适用于无法扩缩的对象，比如。

2、Pod水平自动扩缩特性由 API 资源和控制器实现。资源决定了控制器的行为。 控制器会周期性地调整副本控制器或中的副本数量，以使得类似Pod 平均CPU利用率、平均内存利用率这类观测到的度量值与用户所设定的目标值匹配。

3、Pod水平自动扩缩器的实现是一个控制回路，由kube--控制器管理器的 ---pod--sync- 参数指定周期（默认值为 15 秒）。

2.2.2、API版本

HPA的API有三个版本，通过 api- | grep 可看到,如下图所示：

补充说明：

1、/v1只支持基于CPU指标的缩放

2、/支持内存和自定义指标的缩放

3、/支持内存、自定义指标和、（额外指标）的缩放，但是目前也仅仅是处于beta阶段

2.3、VPA 2.3.1、简介

Pod （VPA）：垂直Pod自动扩缩容，用户无需为其pod中的容器设置最新的资源。配置后，它将根据使用情况自动设置，从而允许在节点上进行适当的调度，以便为每个pod提供适当的资源量。

2.3.2、工作原理

VPA会自动计算这些Pod中容器的流程以及当前的CPU和内存使用情况，并使用这些数据来决定优化的资源限制和请求，以确保这些Pod始终处于较高的资源利用率的状态。例如你有一个Pod使用了CPU的50%，但只请求10%。VPA会认定该Pod消耗的CPU多于请求的CPU，那么它会使工作负载例如会重启Pod来生效新的推荐值，从而实现垂直的资源扩缩容。

这里有几个点需要注意：

1、VPA目前还处于测试阶段，并未大规模生产使用

2、VPA 在伸缩的过程中是通过重启 Pod 来生效调整 和 Limit 的值的，那么很多业务能否支持优雅的重启需要根据实际的情况来判断是否可以接受

3、VPA 扩容的上限便是 Pod 所在 Node 的物理资源大小，所以推荐与节点的自动扩缩容( )一起使用来解决这个问题

4、VPA 与 HPA 不建议一起使用，否则会出现一些预期外的情况

2.4、KPA 2.4.1、简介 2.4.2、工作原理 三、部署-服务

使用HPA之前，需要安装-或者，这样才可以获取节点和pod的资源使用情况。检查-和是否可用最简单的办法是使用top命令，查看是否可以获取到pod的资源使用情况。

-部署参考如下链接： 《部署篇：部署-服务》

补充说明：

1、Metrics server是K8S集群资源使用情况的聚合器
2、从1.8版本开始，Metrics server可以通过yaml文件的方式进行部署
3、Metrics server收集所有node节点的metrics信息

四、HPA实现pod自动扩缩容 4.1、基于CPU指标实现pod自动扩缩容

1、资源下载

K8S之HPA基于CPU指标实现pod自动扩缩容测试用例

2、创建Nginx服务

3、等待1分钟左右的时间,查看hpa

[root@k8s-master-227 k8s-auto-cpu]# kubectl get hpa
NAME                   REFERENCE          TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
nginx-deployment-hpa   Deployment/nginx   0%/30%    1         5         1          51s

4、验证Nginx是否部署成功

5、压测Nginx服务，只是针对CPU做压测

[root@k8s-master-227 k8s-auto-cpu]# while true; do wget -q -O- http://10.48.71.68:80; done

说明：过一段时间等待后，我们通过执行以下命令来看到更高的CPU负载

上面可以看到，CPU消耗已经达到85％，每个pod的目标cpu使用率是30%，所以，Nginx这个创建的pod副本数将调整为3个副本，为什么是3个副本，因为85/30=~3。pod副本数如下所示：

此时，pod副本数如下所示：

6、停止压测Nginx服务

说明：停止对Nginx服务压测，HPA会自动对Nginx这个创建的pod做缩容，等待5分钟后，pod会自动缩容，数量由原来的3个变成1个，如下图所示：

4.2、基于内存指标实现pod自动扩缩容

1、资源下载

K8S之HPA基于内存指标实现pod自动扩缩容测试用例

2、创建Nginx服务

3、等待1分钟左右的时间,查看hpa

[root@k8s-master-227 k8s-auto-memory]# kubectl get hpa
NAME                   REFERENCE          TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
nginx-deployment-hpa   Deployment/nginx   2%/20%    1         5         3          81s

4、验证Nginx是否部署成功

5、压测Nginx服务，只是针对内存做压测

[root@k8s-master-227 k8s-auto-memory]# kubectl exec -it nginx-89ffd9f44-94pds -- /bin/sh
# dd if=/dev/zero of=/tmp/a

说明：过一段时间等待后，我们通过执行以下命令来看到更高的内存负载

上面可以看到，内存消耗已经达到31％，每个pod的目标内存使用率是20%，所以，Nginx这个创建的pod副本数将调整为2个副本，为什么是2个副本，因为31/20=~2。pod副本数如下所示：

此时，pod副本数如下所示：

6、取消对Nginx 内存的压测,删除/tmp/a 这个文件

[root@k8s-master-227 k8s-auto-memory]# kubectl exec -it nginx-89ffd9f44-94pds -- /bin/sh
# rm -f /tmp/a    
# exit

说明：停止对Nginx服务压测，HPA会自动对Nginx这个创建的pod做缩容，等待5分钟后，pod会自动缩容，数量由原来的2个变成1个，如下图所示：

五、VPA实现pod自动扩缩容 5.1、部署-pod-

1、克隆项目

[root@k8s-master-227 k8s-vpa]# wget https://github.com/kubernetes/autoscaler/archive/refs/tags/vertical-pod-autoscaler-0.8.1.zip

说明：当前k8s集群版本为1.20.6，这里使用的项目版本为0.8.1，其中-pod--0.10.0、-pod--0.9.2、-pod--0.9.0在当前k8s集群环境均部署失败，换成0.8.1版本正常。

2、修改部署文件

[root@k8s-master-227 kubernete-autoscale]# cd autoscaler-vertical-pod-autoscaler-0.8.1/vertical-pod-autoscaler/deploy/
[root@k8s-master-227 deploy]# grep imagePullPolicy *
admission-controller-deployment.yaml:          imagePullPolicy: Always
recommender-deployment.yaml:        imagePullPolicy: Always
updater-deployment.yaml:          imagePullPolicy: Always
[root@k8s-master-227 deploy]# sed -i 's#imagePullPolicy: Always#imagePullPolicy: IfNotPresent#g' `grep -rl imagePullPolicy .`
[root@k8s-master-227 deploy]# grep imagePullPolicy *
admission-controller-deployment.yaml:          imagePullPolicy: IfNotPresent
recommender-deployment.yaml:        imagePullPolicy: IfNotPresent
updater-deployment.yaml:          imagePullPolicy: IfNotPresent

3、节点导入镜像

[root@k8s-worker-135 ~]# for i in `ls vpa/images/`;do docker load -i vpa/images/$i;done
0d1435bd79e4: Loading layer [==================================================>]  3.062MB/3.062MB
3d6f95ffd874: Loading layer [==================================================>]  44.99MB/44.99MB
Loaded image: us.gcr.io/k8s-artifacts-prod/autoscaling/vpa-admission-controller:0.8.0
b8cda3fb4e0a: Loading layer [==================================================>]  45.95MB/45.95MB
Loaded image: us.gcr.io/k8s-artifacts-prod/autoscaling/vpa-recommender:0.8.0
9fe5b61fc509: Loading layer [==================================================>]  47.39MB/47.39MB
Loaded image: us.gcr.io/k8s-artifacts-prod/autoscaling/vpa-updater:0.8.0

说明：其它节点按照如上所示导入vpa相关镜像，如果使用的或其它镜像仓库，还需要修改--.yaml、-.yaml、-.yaml三个yaml文件中定义的image镜像名称。

4、部署-pod-

说明：进入--pod--0.8.1/-pod-/hack目录,执行./vpa-up.sh部署脚本，如下图所示：

5、验证vpa是否部署成功，如下图所示：

5.2、实例一（: “Off”） 5.3、实例二（: “On”） 六、KPA实现pod自动扩缩容

1、从HPA到KPA：自动扩缩容深度分析

2、安装考考

KPA只能支持PRS和两种指标，无法接入用户自定义的其他指标。另外，虽然KPA可配置自动扩缩容算法的很多参数，但仍然缺乏可扩展性和可定制性。不过，社区也意识到了这些问题，并在一步步的优化和改进。毕竟相比K8s，还很年轻，相信随着时间推移，会越来越完善和强大，成为领域的事实标准或许就在不远的前方。

总结：整理不易，如果对你有帮助，可否点赞关注一下？

更多详细内容请参考：企业级K8s集群运维实战