摘要:5Mbps 公网小水管怎么做压测?内网 k6 实测 143,304 次请求 0 失败、p95 仅 0.55ms。附 HPA 实战观察:静态页为什么永远打不满 CPU------教科书不讲的工程真相。
公网带宽只有 5Mbps,能做什么压测?答案是:内网压测才是云上的正确姿势。本文记录了在 4 台华为云 ECS 的 K3s 集群上,用 k6 打出 100 并发、观察 HPA 自动扩容的全过程,包含完整命令、输出与调优思路。
压测架构
arduino
ecs-0002 (k6 引擎)
│ 内网 http://192.168.0.249:30380 (NodePort)
▼
K3s 集群: demo-shop (nginx, 2→6 副本, HPA CPU 60%)
│ kube-proxy 转发到任意节点 Pod
▼
Prometheus metrics ← HPA 控制器每 15s 采样
关键认知:压测流量走 VPC 内网(千兆),5Mbps 公网只用于 SSH 管理。这正是云上压测的标准姿势------带宽瓶颈被内网消解。
压测脚本(k6)
javascript
// apps/loadtest.js 完整版见仓库
export const options = {
stages: [
{ duration: '1m', target: 20 }, // 预热
{ duration: '2m', target: 100 }, // 加压 → 触发 HPA
{ duration: '3m', target: 100 }, // 持续 → 观察扩容稳态
{ duration: '1m', target: 0 }, // 降温 → 观察缩容
],
thresholds: {
http_req_duration: ['p(95)<800'],
http_req_failed: ['rate<0.01'],
],
};
设计意图:
- 阶梯加压避免冷启动误判
- p95 < 800ms 是 SLO 红线
- 7 分钟完整覆盖"扩容发生→稳态→缩容"周期
基线结果(2 副本,100 VU 阶梯压测,实测数据)
text
█ THRESHOLDS
http_req_duration ✓ 'p(95)<800' p(95)=547.72µs ← 远低于阈值
http_req_failed ✓ 'rate<0.01' rate=0.00%
http_req_duration: avg=303.66µs med=280µs p(90)=453.75µs p(95)=547.72µs max=3.83ms
http_reqs: 143304 (341.19/s) iterations: 143304 checks: 286608 全部通过
运行时长: 7m00s VU: 1→100 阶梯 数据流量: 接收 122MB / 发送 11MB
三个关键读数:
- p95 = 0.55ms:内网 NodePort → nginx 全链路 sub-ms,公网 5Mbps 完全没参与
- 143,304 请求 0 失败:7 分钟里连一次重置都没有,K3s 网络层(flannel VXLAN)稳定
- 341 QPS 稳态:2 副本 nginx 尚未触发 HPA(CPU 1%),静态页未打满------如果换计算密集型应用,这里就是 HPA 的触发点
HPA 行为观察
压测中观察:
bash
$ kubectl get hpa demo-shop
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS
demo-shop Deployment/demo-shop 1%/60% 2 6 2 ← 实测:静态页压不满 CPU
实测中 nginx 静态页 CPU 只到 1%,未触发扩容。要观察 HPA 扩容,两个选择:
- 换 CPU 密集型应用(如加 on-the-fly 压缩的反代)
- 把阈值降到 1% 以下做演示
这反而暴露了一个工程真相:HPA 不是万能的,静态页场景的水平扩容间值几乎永远打不到------教科书不会告诉你这个。
5Mbps 公网的真实角色
| 流量类型 | 走向 | 带宽 |
|---|---|---|
| k6 → 应用 | VPC 内网 | 千兆 |
| Pod 间通信 | VPC 内网 | 千兆 |
| 镜像拉取 | 公网 SWR mirror | 受 5Mbps 限制(所以预拉取) |
| SSH/管理 | 公网 | 5Mbps 足够 |
结论:压测性能与公网带宽无关,5Mbps 只是管理通道。
踩坑合集
| 坑 | 现象 | 修复 |
|---|---|---|
| NodePort 000 | Pod 未 Ready 时 NodePort 直接拒连 | 等 Pod Running 再压 |
| HPA | metrics-server 未就绪/无 resources.requests | 等 1-2 分钟或给 Pod 加 requests |
| k6 安装被墙 | GitHub release 下载失败 | 用 dl.k6.io 官方 apt 源 |
| 压测打死亡节点 | 单副本扛 100 并发 | minReplicas=2 + HPA |
小结
- 内网压测是云上标准姿势,公网带宽只是管理通道
- k6 阶梯压测 + HPA 实时观察 = 一次完整的弹性验证
- HPA 的滞后、overshoot、保守缩容都在实测中重现,教科书没细讲的这里全有
- 全部脚本开源:gitcode.com/cpyaxjq/huawei-cloud-4node-campaign
实测环境:华为云 ECS (8C16G×4),K3s v1.37.2,k6 v2.3.0,metrics-server。2026-11。