IT评测·应用市场-qidao123.com

标题: kubernetes v1.29.XX版本HPA、KPA、VPA并压力测试 [打印本页]

---

作者: 大连全瓷种植牙齿制作中心    时间: 2025-1-20 18:33
标题: kubernetes v1.29.XX版本HPA、KPA、VPA并压力测试
序言：

在大型电商、购物、直播活动期间，对于火爆流量的激增，如何保障业务稳定并且做到资源不浪费，自动接纳。
场景：kubernetes 原生容器化承载业务流量（非云环境）
方案：kubernetes自带HPA、KPA、VPA板块
板块选择

一、KPA板块

KPA（Knative Pod Autoscaler）基于请求数对Pod自动扩缩容，KPA的主要限定在于它不支持基于CPU的自动扩缩容。

• 根据并发请求数实现自动扩缩容
  
• 设置扩缩容界限实现自动扩缩容
  

扩缩容界限是指应用程序提供服务的最小和最大Pod数量。通过设置应用程序服务的最小和最大Pod数量实现自动扩缩容。
二、HPA板块

国内HPA介绍地址：

1. https://kubernetes.p2hp.com/docs/tasks/run-application/horizontal-pod-autoscale/

复制代码

程度扩缩容意味着更多的pod被创建和清理，支持均匀 CPU 使用率、均匀内存使用率或你指定的任何其他自界说等指标，自动伸缩Replication Controller、Deployment 大概Replica Set 中的 Pod 数量。

• 基于kube-controller-manager控制器界说的服务启动参数horizontal-pod-autoscaler-sync-period（default 15s）周期性检测CPU的使用率
  
• HorizontalPodAutoscaler 被实现为 Kubernetes API 资源和控制器。
  
• HorizontalPodAutoscaler 的常见用途是将其配置为从聚合 API
  （metrics.k8s.io、custom.metrics.k8s.io 或 external.metrics.k8s.io）获取指标。
  

注意：metrics.k8s.io API 通常由名为 Metrics Server 的插件提供，必要单独启动，部署方案：

1. https://blog.csdn.net/binqian/article/details/144170031

复制代码

优缺点
长处：

• 支持滚动升级时扩缩
  
  
  
  
• HPA 的任何目标资源都可以基于此中的 Pods 的资源用量来实现扩缩。
  
  
  
  
• 支持容器资源指标
  
• 可扩展性强，支持自界说指标
  
• 单独对 Metrics API 的支持
  
  
  
  

缺点：

• HPA的流程涉及到POD从0到1流程的创建，流程中的网络问题比较敏感
  
• 现有场景都是依赖Metric Server去动态监测
  
• 程度扩展必要临时大概恒久有充足的空闲资源
  
• 现有常用的副本控制器不支持 DaemonSet
  
• 参与自动伸缩的副本控制器不得指定副本数量，容易导致HPA异常
  

核心参数

• ScaleTargetRef：指定 HPA 将要作用的资源对象，如 Deployment、Replica Set 或 RC 的名称。
  
• MinReplicas：最小副本数，即使在负载很低时也不会低于这个数量。
  
• MaxReplicas：最大副本数，即使在负载很高时也不会凌驾这个数量。
  
• Metrics：界说用于触发伸缩的度量标准和目标值。常见：targetCPUUtilizationPercentage
  

用例分析

1. ---
2. apiVersion: autoscaling/v1
3. kind: HorizontalPodAutoscaler
4. metadata:
5.   name: xxxx #自定义名称
6. spec:
7.   scaleTargetRef:
8.     apiVersion: apps/v1
9.     kind: Deployment #指定要自动缩放的目标对象，这里是一个Deployment
10.     name: xxxx #指定deployment的标签name
11.   minReplicas: 1
12.   maxReplicas: 5
13. #自动扩缩的副本数，最大5，最小1
14.   targetCPUUtilizationPercentage: 50 #CPU利用率的阀值50%

复制代码

压力测试
本机环境如下：

业务yaml

1. [root@k8s-docker-master ~]# cat hpa-test.yaml
2. apiVersion: apps/v1
3. kind: Deployment
4. metadata:
5.   name: centos-test
6.   labels:
7.     test: centos
8. spec:
9.   replicas:
10.   selector:
11.     matchLabels:
12.       test: centos
13.   template:
14.     metadata:
15.       labels:
16.         test: centos
17.     spec:
18.       containers:
19.         - name: centos
20.           image: centos:7
21.           command: ["/bin/bash", "-c", "yum -y install epel-release;yum -y install stress;sleep 3600"]
22.           resources:
23.             limits:
24.               cpu: "1"
25.               memory: 512Mi
27. ---
28. apiVersion: autoscaling/v1
29. kind: HorizontalPodAutoscaler
30. metadata:
31.   name: hpa-centos7
32. spec:
33.   scaleTargetRef:
34.     apiVersion: apps/v1
35.     kind: Deployment
36.     name: centos-test
37.   minReplicas: 1
38.   maxReplicas: 3
39.   targetCPUUtilizationPercentage: 50
40.   
41. [root@k8s-docker-master ~]# kubectl apply -f hpa-test.yaml
42. deployment.apps/centos-test configured
43. horizontalpodautoscaler.autoscaling/hpa-centos7 created
44. [root@k8s-docker-master ~]# kubectl get pod -A | grep centos-test
45. default            centos-test-594d5479c8-tf44w                1/1     Running   0          4m37s
46. [root@k8s-docker-master ~]# kubectl get horizontalpodautoscaler -A
47. NAMESPACE   NAME          REFERENCE                TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
48. default     hpa-centos7   Deployment/centos-test   0%/50%    1         3         1          66s

复制代码

满足阈值的开始扩容，低于开始缩容，这里显示REPLICAS数值为2不跳动是因为扩容很快，缩容很慢导致。建议弄一个新的环境去压力测试。
三、VPA板块

VPA 全称 Vertical Pod Autoscaler,即垂直 Pod 自动扩缩容,它根据容器资源使用率自动设置 CPU 和内存的requests, 以便为每个 Pod 提供得当的资源。
既可以缩小过度请求资源的容器，也可以根据其使用环境随时提升资源不敷的容量
使用 VPA 的意义:

• Pod 资源用其所需，提升集群节点使用服从;
  
• 不必运行基准测试任务来确定 CPU 和内存请求的符合值;
  
• VPA可以随时调整CPU和内存请求,无需人为操作，因此可以减少维护时间。
  

注意：VPA目前还没有生产就绪，在使用之前必要了解资源调节对应用的影响。
VPA架构图

VPA 主要包括两个组件：
1）VPA Controller

• Recommendr：给出 pod 资源调整建议
  
• Updater：对比建议值和当前值，差别等时驱逐 Pod （evicts pods）
  2）VPA Admission Controller
  
• Pod 重建时将 Pod 的资源请求量修改为保举值
  utilization and events history（获取历史使用率和变乱）
  utilization and events （realtime）（获取实时使用率和变乱）
  

工作流程

VPA只监听pod和使用Updater驱除pod，保举数值
真正执行覆写（overwrites pod spec）是VPA Admission Crotroller
流程如下：

• 若资源使用率发生变化，Recommender会对当前资源使用环境和历史资源使用环境，进行分析盘算资源使用的阈值，若对比盘算值和当前值差别等会给出资源调整建议（set
  recommendation过程）
  
• Updater根据建议调用API去除pod
  
• pod被驱除后就会触发副本控制器进行重建，在这重建过程中VPA Admission
  Crotroller会监听拦截，根据Recommended resources来调整资源
  
• VPA Admission Crotroller执行overwrites pod spec更改pod资源信息对pod进行重建
  

VPA优缺点
长处：

• VPA自动对集群内资源进行盘算调治，低落运维成本
  
• VPA垂直扩展便于pod资源管理
  
• VPA类似于资源动态分配，能准确的使用掉分配的资源，不造成浪费
  

缺点：

• VPA成熟度不敷，涉及到重建pod，容易调治到其他node节点
  
• VPA 不会驱除无副本控制器管理下的pod
  
• 不能和前者监控CPU、内存为度量的HPA同时运行（若HPA有定制化大概外部资源可以）
  
• 强依赖admission webhook准入控制器，不能跟其他admission webhook辩论
  
• VPA会处理绝大多数的OOM变乱，但无法做到100%
  
• VPA未应用在大型集群的经验，生态范围太小
  
• VPA 通过Remmonder盘算的阈值可能会凌驾当前node的资源上线，导致pod重建后pending，无法正常调治
  
• 多个VPA同时调治同一个pod 会造成未界说的行为
  

总体上来说，毛病偏大，特别是对pod重建具有对业务很大的冲击性，容易导致业务瓦解，听说在v1.26版本后有新功能实现可以缓解破坏性重建pod带来的风险
部署vpa操作环境
这里不做详细解释，可以看调整下面的链接去查看操作部署，部署流程和遇到问题

1. git clone -b vpa-release-0.12 https://github.com/kubernetes/autoscaler.git

复制代码

用例分析
之前HPA的压测用例无法更直观看到效果，重新在别的blog上找了一个deployment进行测试
1、args用例主要写一个死循环压CPU使用率

1. cat > vpa-deploy.yaml << EOF
2. apiVersion: apps/v1
3. kind: Deployment
4. metadata:
5.   name: centos-test
6. spec:
7.   selector:
8.     matchLabels:
9.       app: centos-test
10.   replicas: 2
11.   template:
12.     metadata:
13.       labels:
14.         app: centos-test
15.     spec:
16.       securityContext:
17.         runAsNonRoot: true
18.         runAsUser: 65534
19.       containers:
20.         - name: centos-test
21.           image: centos:7
22.           resources:
23.             requests:
24.               cpu: 100m
25.               memory: 50Mi
26.           command: ["/bin/sh"]
27.           args:
28.             - "-c"
29.             - "while true; do timeout 0.5s yes >/dev/null; sleep 0.5s; done"
30. EOF

复制代码

2、启动后查看pod资源使用环境，cpu很快就凌驾设定的100M

1. [root@k8s-docker-master ~]# kubectl apply -f vpa-deploy.yaml
2. deployment.apps/centos-test created
3. [root@k8s-docker-master ~]# kubectl get pod -A
4. NAMESPACE          NAME                                        READY   STATUS    RESTARTS        AGE
5. calico-apiserver   calico-apiserver-7bccbcbb5-d7wfl            1/1     Running   2 (5h52m ago)   2d4h
6. calico-apiserver   calico-apiserver-7bccbcbb5-j2g8k            1/1     Running   2 (5h52m ago)   2d4h
7. calico-system      calico-kube-controllers-6bd5f8b7b8-cr8g4    1/1     Running   1 (5h52m ago)   2d5h
8. calico-system      calico-node-cdt57                           1/1     Running   1 (5h52m ago)   2d5h
9. calico-system      calico-node-g27dg                           1/1     Running   1 (5h52m ago)   2d2h
10. calico-system      calico-typha-f75945f64-hbhnn                1/1     Running   1 (5h52m ago)   2d5h
11. calico-system      csi-node-driver-mgzhp                       2/2     Running   2 (5h52m ago)   2d5h
12. calico-system      csi-node-driver-mknl4                       2/2     Running   2 (5h52m ago)   2d2h
13. default            centos-test-7bbf8d4dbb-8bxz5                1/1     Running   0               6s
14. default            centos-test-7bbf8d4dbb-nqlnr                1/1     Running   0               6s
15. kube-system        coredns-857d9ff4c9-8cl4p                    1/1     Running   1 (5h52m ago)   2d7h
16. kube-system        coredns-857d9ff4c9-nt2vf                    1/1     Running   1 (5h52m ago)   2d7h
17. kube-system        etcd-k8s-docker-master                      1/1     Running   2 (5h52m ago)   2d7h
18. kube-system        kube-apiserver-k8s-docker-master            1/1     Running   2 (5h52m ago)   2d7h
19. kube-system        kube-controller-manager-k8s-docker-master   1/1     Running   4 (5h52m ago)   2d7h
20. kube-system        kube-proxy-44cf5                            1/1     Running   1 (5h52m ago)   2d2h
21. kube-system        kube-proxy-7znvm                            1/1     Running   1 (5h52m ago)   2d7h
22. kube-system        kube-scheduler-k8s-docker-master            1/1     Running   5 (5h52m ago)   2d7h
23. kube-system        metrics-server-86f484f564-dsnb7             1/1     Running   1 (5h52m ago)   2d1h
24. kube-system        vpa-admission-controller-b6d8f7-scwnm       1/1     Running   0               77m
25. kube-system        vpa-recommender-67c99b46db-dxxf8            1/1     Running   0               130m
26. kube-system        vpa-updater-7c4dd558df-jtpb7                1/1     Running   0               130m
27. tigera-operator    tigera-operator-7d5ddd8b6d-4qx7w            1/1     Running   5 (5h52m ago)   2d5h
28. [root@k8s-docker-master ~]# kubectl top pod
29. NAME                           CPU(cores)   MEMORY(bytes)
30. centos-test-7bbf8d4dbb-8bxz5   513m         3Mi
31. centos-test-7bbf8d4dbb-nqlnr   506m         1Mi

复制代码

3、VPA资源核心参数解释

• targetRef：指定哪个deployment资源和metadata name
  
• minAllowed：最小值
  
• maxAllowed：最大值
  
• controlledResources：限定的资源范例
  

4、创建一个VPA资源

1. cat > vpa.yaml << EOF
2. apiVersion: "autoscaling.k8s.io/v1"
3. kind: VerticalPodAutoscaler
4. metadata:
5.   name: centos-test-vpa
6. spec:
7.   # recommenders field can be unset when using the default recommender.
8.   # When using an alternative recommender, the alternative recommender's name
9.   # can be specified as the following in a list.
10.   # recommenders:
11.   # - name: 'alternative'
12.   targetRef:
13.     apiVersion: "apps/v1"
14.     kind: Deployment
15.     name: centos-test
16.   resourcePolicy:
17.     containerPolicies:
18.       - containerName: '*'
19.         minAllowed:
20.           cpu: 100m
21.           memory: 50Mi
22.         maxAllowed:
23.           cpu: 1
24.           memory: 500Mi
25.         controlledResources: ["cpu", "memory"]
26. EOF
27. [root@k8s-docker-master ~]# kubectl apply -f vpa.yaml
28. verticalpodautoscaler.autoscaling.k8s.io/centos-test-vpa created

复制代码

5、查看vpa是否给出建议：kubectl describe vpa 下述已给出建议

1. [root@k8s-docker-master ~]# kubectl describe vpa
2. Name:         centos-test-vpa
3. Namespace:    default
4. Labels:       <none>
5. Annotations:  <none>
6. API Version:  autoscaling.k8s.io/v1
7. Kind:         VerticalPodAutoscaler
8. Metadata:
9.   Creation Timestamp:  2025-01-17T09:17:23Z
10.   Generation:          2
11.   Resource Version:    275328
12.   UID:                 2967462c-6ebc-446a-b9b6-18f75010e587
13. Spec:
14.   Resource Policy:
15.     Container Policies:
16.       Container Name:  *
17.       Controlled Resources:
18.         cpu
19.         memory
20.       Max Allowed:
21.         Cpu:     1
22.         Memory:  500Mi
23.       Min Allowed:
24.         Cpu:     100m
25.         Memory:  50Mi
26.   Target Ref:
27.     API Version:  apps/v1
28.     Kind:         Deployment
29.     Name:         centos-test
30.   Update Policy:
31.     Update Mode:  Auto
32. Status:
33.   Conditions:
34.     Last Transition Time:  2025-01-17T09:18:11Z
35.     Status:                True
36.     Type:                  RecommendationProvided
37.   Recommendation:
38.     Container Recommendations:
39.       Container Name:  centos-test
40.       Lower Bound:
41.         Cpu:     356m
42.         Memory:  262144k
43.       Target:
44.         Cpu:     587m
45.         Memory:  262144k
46.       Uncapped Target:
47.         Cpu:     587m
48.         Memory:  262144k
49.       Upper Bound:
50.         Cpu:     1
51.         Memory:  500Mi
52. Events:          <none>

复制代码

6、查看是否开始重建pod kubectl get pod -A 这里已开始重建，但这边的memory不敷，没办法（注意包管node节点资源高于vpa保举的容量范围，以免重建处于pending状态）这里pod已开始重建

1. [root@k8s-docker-master ~]# kubectl get pod -A
2. NAMESPACE          NAME                                        READY   STATUS    RESTARTS     AGE
3. calico-apiserver   calico-apiserver-7bccbcbb5-d7wfl            1/1     Running   2 (6h ago)   2d5h
4. calico-apiserver   calico-apiserver-7bccbcbb5-j2g8k            1/1     Running   2 (6h ago)   2d5h
5. calico-system      calico-kube-controllers-6bd5f8b7b8-cr8g4    1/1     Running   1 (6h ago)   2d5h
6. calico-system      calico-node-cdt57                           1/1     Running   1 (6h ago)   2d5h
7. calico-system      calico-node-g27dg                           1/1     Running   1 (6h ago)   2d2h
8. calico-system      calico-typha-f75945f64-hbhnn                1/1     Running   1 (6h ago)   2d5h
9. calico-system      csi-node-driver-mgzhp                       2/2     Running   2 (6h ago)   2d5h
10. calico-system      csi-node-driver-mknl4                       2/2     Running   2 (6h ago)   2d2h
11. default            centos-test-7bbf8d4dbb-dhxx5                0/1     Pending   0            71s
12. default            centos-test-7bbf8d4dbb-nqlnr                1/1     Running   0            7m54s
13. kube-system        coredns-857d9ff4c9-8cl4p                    1/1     Running   1 (6h ago)   2d7h
14. kube-system        coredns-857d9ff4c9-nt2vf                    1/1     Running   1 (6h ago)   2d7h
15. kube-system        etcd-k8s-docker-master                      1/1     Running   2 (6h ago)   2d7h
16. kube-system        kube-apiserver-k8s-docker-master            1/1     Running   2 (6h ago)   2d7h
17. kube-system        kube-controller-manager-k8s-docker-master   1/1     Running   4 (6h ago)   2d7h
18. kube-system        kube-proxy-44cf5                            1/1     Running   1 (6h ago)   2d2h
19. kube-system        kube-proxy-7znvm                            1/1     Running   1 (6h ago)   2d7h
20. kube-system        kube-scheduler-k8s-docker-master            1/1     Running   5 (6h ago)   2d7h
21. kube-system        metrics-server-86f484f564-dsnb7             1/1     Running   1 (6h ago)   2d1h
22. kube-system        vpa-admission-controller-b6d8f7-scwnm       1/1     Running   0            85m
23. kube-system        vpa-recommender-67c99b46db-dxxf8            1/1     Running   0            137m
24. kube-system        vpa-updater-7c4dd558df-jtpb7                1/1     Running   0            137m
25. tigera-operator    tigera-operator-7d5ddd8b6d-4qx7w            1/1     Running   5 (6h ago)   2d5h

复制代码

7、查看最新启动pod的requests信息是否跟vpa的建议是否同等：

总结：

1. VPA：基于CPU、men等资源容量的历史使用率和实时使用率进行伸缩，破坏性的重建pod进行垂直自动伸缩还是不符合现阶段主流，还有待考量，不推荐使用。
2. HPA：基于cpu、mem等资源容量实时使用率进行伸缩，现阶段自动伸缩的主流，但不支持DaemonSet。
3. KPA：基于请求书进行伸缩，不支持基于CPU的自动扩缩容，作用点不大。

复制代码

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 IT评测·应用市场-qidao123.com (https://dis.qidao123.com/)

Powered by Discuz! X3.4