K8s压力测试实战：从HPA动态扩缩容到资源优化
1. 为什么需要K8s压力测试？
当你把业务迁移到Kubernetes集群后，最怕遇到什么情况？我猜一定是半夜被报警叫醒，发现服务因为流量激增而崩溃。去年我们团队就经历过一次，促销活动带来的流量是平时的20倍，HPA（Horizontal Pod Autoscaler）没有按预期扩容，导致整个服务雪崩。这就是不做压力测试的代价。
压力测试不仅仅是模拟高并发请求那么简单，它更像是对集群的一次全面体检。通过压测我们可以：
- 验证服务极限：知道你的服务在崩溃前能承受多少流量，就像知道桥梁的最大承重
- 优化资源配置：避免给Pod分配过多资源造成浪费，我见过一个Node.js服务配置了4核CPU，实际只用0.5核
- 检验HPA可靠性：动态扩缩容不是配置好就能用的，需要实测验证触发条件是否准确
2. HPA动态扩缩容实战
2.1 HPA工作原理揭秘
HPA就像集群的智能空调系统，当温度（CPU/内存使用率）超过设定阈值时，会自动增加Pod数量来降温。但很多人不知道的是，HPA有这三个关键参数决定它的灵敏度：
metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 50 # 这是黄金参数 behavior: # 这是多数人忽略的调速器 scaleDown: stabilizationWindowSeconds: 300 # 缩容冷却时间 policies: - type: Percent value: 10 # 每次最多减少10%的Pod实测发现，当averageUtilization设为50%时，如果突然遇到流量高峰，HPA可能需要3-5分钟才能完成扩容。这时可以配合behavior参数调整扩缩容速度：
behavior: scaleUp: stabilizationWindowSeconds: 0 policies: - type: Percent value: 100 # 允许一次性翻倍扩容 - type: Pods value: 4 # 或者每次至少增加4个Pod2.2 真实压测场景演示
我们用php-apache做测试对象，先部署基础服务：
kubectl apply -f - <<EOF 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 resources: requests: cpu: 200m limits: cpu: 500m EOF然后用hey工具模拟真实流量：
kubectl run hey --image=rakyll/hey -- \ -c 200 -n 1000000 -q 50 http://php-apache.default.svc.cluster.local这时候通过Grafana观察，会发现一个有趣现象：虽然CPU使用率已经超过80%，但HPA没有立即扩容。这是因为HPA默认采集的是最近1分钟的平均值，瞬时峰值不会触发扩容。这就是为什么生产环境需要结合自定义指标（如QPS）来做更灵敏的扩容判断。
3. 资源优化实战技巧
3.1 Requests和Limits的黄金比例
经过上百次压测，我总结出资源配置的"3:5法则"：
- Requests设为实际需求的60%（如实际需要300m，就设200m）
- Limits设为Requests的1.5-2倍
这样配置的好处是：
- 提高集群资源利用率（不会因为requests过高导致碎片）
- 给突发流量留出缓冲空间
- 避免OOM Killer误杀Pod
resources: requests: cpu: 200m memory: 256Mi limits: cpu: 500m memory: 512Mi3.2 垂直扩缩容（VPA）的隐藏用法
虽然HPA负责水平扩缩容，但当遇到Java这类内存敏感型应用时，还需要配合VPA（Vertical Pod Autoscaler）：
# 安装VPA组件 helm install vpa recommender \ --repo https://charts.fairwinds.com/stable \ --set recommender.extraArgs.v=4配置自动内存调整：
apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: my-app-vpa spec: targetRef: apiVersion: "apps/v1" kind: Deployment name: my-app updatePolicy: updateMode: "Auto"实测发现，VPA可以将内存配置优化到最佳状态，减少30%以上的内存浪费。但要注意，VPA会导致Pod重建，不适合有状态服务。
4. 高级压测方案设计
4.1 分布式压测架构
当需要模拟10万级并发时，单机压测工具就不够用了。我们在生产环境使用这样的架构：
[K6控制中心] -> [K6 Worker Pods] -> [被测服务]部署命令：
kubectl apply -f - <<EOF apiVersion: apps/v1 kind: Deployment metadata: name: k6-worker spec: replicas: 10 # 10个worker节点 template: spec: containers: - name: k6 image: loadimpact/k6 command: ["sleep"] args: ["infinity"] EOF然后通过k6的分布式执行模式：
kubectl exec -it k6-worker-0 -- \ k6 run --vus 1000 --duration 30m \ --out cloud \ script.js4.2 混沌工程结合压测
真正的稳定性测试需要引入故障。我们使用chaos-mesh模拟网络延迟：
apiVersion: chaos-mesh.org/v1alpha1 kind: NetworkChaos metadata: name: network-delay spec: action: delay mode: one selector: namespaces: - default labelSelectors: "app": "php-apache" delay: latency: "500ms" correlation: "100" jitter: "100ms"在压测过程中随机注入网络延迟、Pod故障等异常，可以暴露出更多潜在问题。比如我们就曾发现当Node节点CPU负载超过70%时，kube-proxy的转发性能会急剧下降。
5. 监控与数据分析
压测不是简单的发请求，关键是要建立完整的监控链路。我们的监控矩阵包括：
| 监控层级 | 工具 | 关键指标 |
|---|---|---|
| 基础设施 | Node Exporter | CPU steal、磁盘IO等待 |
| 容器运行时 | cAdvisor | 容器内存泄漏 |
| 应用性能 | Prometheus | 99线响应时间 |
| 业务指标 | 自定义Exporter | 订单创建成功率 |
特别是要关注这些黄金指标：
- 饱和度：CPU throttling次数（表示limit设置过低）
- 错误率：5xx错误增长趋势
- 流量：QPS与Pod数量的比值
- 延迟：P99响应时间变化
配置Prometheus告警规则示例：
- alert: HighCPUThrottling expr: rate(container_cpu_cfs_throttled_seconds_total{container!=""}[5m]) > 0.1 for: 10m labels: severity: warning annotations: summary: Pod {{ $labels.pod }} CPU throttling过高压测结束后，用Grafana的Heatmap面板分析响应时间分布，往往能发现隐藏的性能瓶颈。比如我们发现当MySQL连接数超过配置的max_connections时，响应时间会从50ms直接飙升到2000ms。
经过三年多的K8s压测实践，最大的体会是：没有经过压测的HPA配置就是耍流氓。每次业务大促前，我们都会用历史峰值流量的3倍进行全链路压测，这已经成为保障稳定性的最后一道防线。