k8s压力测试文档

k8s压力测试文档

为什么要进行对k8s中的集群资源做压力测试？

1. 确保高负载下的服务可用性

2. 验证资源调度与分配机制

3. 验证集群弹性伸缩的上限

4. 避免资源过度配置或浪费

k8s支持HAP-动态pod扩容

1. 基于 CPU / 内存指标

2. 基于自定义指标（Custom Metrics）

3. 基于外部指标（External Metrics）

一、什么是压测？（性能测试的核心概念）

压测（压力测试，Performance Testing）是通过模拟真实或超出预期的负载场景，测试系统在高并发、大数据量下的性能表现，验证其稳定性、响应能力和资源利用率的过程。在 Kubernetes（K8s）环境中，压测的核心目标是评估容器编排系统、应用服务及底层基础设施在负载压力下的整体表现。

二、K8s 压测的核心方法与工具

1. 通用压测工具：JMeter、K6、Locust （模拟http连接负载，选一个复杂的部署实现）

2. 分布式压测工具：k6 with Kubernetes、PTS （支持在k8s集群内部署分布式压测节点，模型大规模并发）

实验目标

1. 理解 Pod 资源请求（requests）和限制（limits）对性能的影响。

2. 验证 Horizontal Pod Autoscaler（HPA）在压力下的自动扩缩容行为。

3. 观察不同资源配置下，Pod 的稳定性和服务响应时间变化。

环境准备

在本地的k8s集群中部署Prometheus和Grafana监控指标

1. 创建测试的命令空间

kubectl create ns heml

2. 添加Helm（k8s中的包管理器），使用Helm一键部署Prometheus

# 安装helm
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh

3. 使用helm快速安装Prometheus和Grafana

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

# 安装Prometheus和Grafana,指定namespace
helm install prometheus prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set prometheus.prometheusSpec.podMonitorSelectorNilUsesHelmValues=false \
  --set prometheus.prometheusSpec.serviceMonitorSelectorNilUsesHelmValues=false

4. 部署k6压测工具（出现问题无法部署） - 列出大致步骤

5. 部署php服务

# php-apache.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: php-apache
spec:
  replicas: 1
  selector:
    matchLabels:
      app: php-apache
  template:
    metadata:
      labels:
        app: php-apache
    spec:
      containers:
      - name: php-apache
        image: k8s.gcr.io/hpa-example
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 200m  # 每个Pod请求200m CPU
          limits:
            cpu: 500m  # 每个Pod最多使用500m CPU
---
apiVersion: v1
kind: Service
metadata:
  name: php-apache
spec:
  ports:
  - port: 80
  selector:
    app: php-apache
  type: ClusterIP

6. 部署HPA 基于CPU使用率自动调整pod数量

# php-apache-hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50  # 当平均CPU使用率超过50%时扩容

7. 部署完成后查看hpa状态

kubectl get hpa php-apache-hpa

NAME             REFERENCE               TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
php-apache-hpa   Deployment/php-apache   0%/50%    1         10        7          11m

8. 简单压测-使用**kubectl run** + **busybox**

# 创建一个Pod执行无限循环请求，产生负载
kubectl run -i --tty load-generator --image=busybox /bin/sh

# 在Pod内执行以下命令（持续发送请求）
while true; do wget -q -O- http://php-apache; done

# 查看效果  (一开始)
(base) [root@master1 helm]# kubectl top pods
NAME                              CPU(cores)   MEMORY(bytes)   
load-generator                    13m          0Mi             
nginx                             0m           1Mi             
nginx-deployment-676fcc46-b88jx   0m           1Mi             
nginx-deployment-676fcc46-jbtz9   0m           1Mi             
nginx-deployment-676fcc46-wlb6r   0m           1Mi             
php-apache-dfddccc6c-m8jfb        501m         8Mi  

# 执行一段时间后
php-apache-dfddccc6c-488jb        116m         8Mi             
php-apache-dfddccc6c-5h4t8        126m         8Mi             
php-apache-dfddccc6c-m8jfb        132m         8Mi             
php-apache-dfddccc6c-ptpmv        112m         8Mi             
php-apache-dfddccc6c-wjknt        120m         8Mi 

# 动态查看hpa replicas发生动态变化
NAME             REFERENCE               TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
php-apache-hpa   Deployment/php-apache   44%/50%   1         10        7          6m52s

9. 使用**hey**工具（更精准的压测）

# 部署hey压测Pod
kubectl run hey --image=rakyll/hey -- \
  -c 50 -n 1000000 -q 100 http://php-apache

# 参数说明：
# -c 50：50个并发请求
# -n 1000000：总共发送100万请求
# -q 100：每秒最多100个请求

10. 进入pod内部压测

• 当发送requests请求时，对其做限制的是requests设置的限制值，如果并非request请求，如pod自身产生的cpu消耗则会走limit标签限制资源

• 在pod内部进行压测时：运行cpu密集型任务，当cpu使用率达到负载时不在升高，针对内存，当内存超过预期之后，pod会直接挂掉，如果配置了 相应策略，比如deployment启动或者设定了重启策略为Always则会重启pod