如何在Debian上进行K8S性能测试

在 Debian 上进行 Kubernetes 性能测试

一环境与工具准备

集群与节点
- 建议准备至少3 节点（建议规格16C/64G）的 Debian 集群，网络使用 CNI 插件（Calico/Cilium），存储对比本地盘/云盘/分布式存储的 IOPS/时延差异。
监控与可观测性
- 部署 Prometheus + Grafana，采集节点、Pod、kubelet、API Server、etcd 等关键指标；为调度、资源、API 设置告警阈值，如：节点 CPU 利用率**>85%持续 1 分钟、API Server P99 延迟 >1s、调度延迟>500ms**。
压测与基准工具
- 应用层：k6、Locust、Fortio、Vegeta（HTTP/gRPC、复杂场景与持续压测）。
- 集群级：Clusterloader2（官方可扩展性与性能测试框架）、kube-burner（自定义工作负载压力）、kubemark（模拟大规模节点）。
- 网络/存储：iperf3、netperf（吞吐/延迟）、fio（持久卷 IOPS/时延）。

二快速上手应用层 HTTP 压测

部署测试目标

启动 Nginx 作为被测服务，暴露 Service：

kubectl create deployment nginx --image=nginx:1.25 --replicas=3
kubectl expose deployment nginx --port=80

在集群内发起压测（避免本地到集群的网络瓶颈）

使用 k6（推荐）：

kubectl run k6 --image=grafana/k6:latest --restart=Never -it --rm \
  --env K6_OUT=json=/results/k6.json \
  -- ./run - < scripts/nginx-test.js

scripts/nginx-test.js 示例：

import http from 'k6/http';
import { sleep } from 'k6';
export let options = { vus: 50, duration: '5m' };
export default function () {
  http.get('http://nginx/');
  sleep(0.2);
}

使用 Fortio（精确延迟分布、支持 gRPC/HTTP2）：

kubectl run fortio --image=fortio/fortio --restart=Never -it --rm \
  -- fortio load -c 50 -t 5m -qps 200 http://nginx/

观测与判定
- 在 Grafana 查看 P50/P95/P99 延迟、QPS、错误率；结合 Prometheus 告警规则（如 P99 延迟、CPU 过载）判断是否满足 SLO。

三集群级基准测试

Pod 密度与调度吞吐（Clusterloader2）

示例配置（创建 100 个 Nginx Pod 的密度测试）：

apiVersion: clusterloader2/v1alpha1
kind: TestingConfig
testing:
- name: pod-density
  jobs:
  - name: create-pods
    jobType: Create
    objectBundle:
    - basename: nginx
      objectTemplatePath: "templates/nginx-deployment.yaml"
    replicas: 100

执行测试并导出报告：

./clusterloader2 run --testconfig=config/density.yaml \
  --provider=local --nodes=3 --report-dir=/results

关键观察点：节点资源使用率≈85%时的调度成功率、kubelet GC 频率、kube-scheduler CPU 占用、PodStartupLatency、API Responsiveness。

大规模模拟（kubemark）
- 通过 hollow node 模拟 100/200/500 节点规模，验证控制面 API 调用延迟（Mutating/Read-only） 与 Pod 启动延迟 是否满足社区 SLI/SLO（如 Mutating API P99 < 1s、只读 API P99 < 30s）。

存储 IOPS/时延（Fio）

在 Pod 中运行 fio 测试 PVC（示例为随机写 4K）：

apiVersion: batch/v1
kind: Job
metadata:
  name: fio-test
spec:
  template:
    spec:
      containers:
      - name: fio
        image: fio/fio:latest
        command: ["fio", "--name=randwrite", "--ioengine=libaio",
                  "--rw=randwrite", "--bs=4k", "--direct=1",
                  "--size=1G", "--numjobs=4", "--runtime=60",
                  "--filename=/mnt/testfile", "--group_reporting"]
        volumeMounts:
        - name: testvol
          mountPath: /mnt
      volumes:
      - name: testvol
        persistentVolumeClaim:
          claimName: test-pvc
      restartPolicy: Never

关注 IOPS、带宽、延迟分布，对比不同 StorageClass 表现。

四网络与自动扩缩容专项

网络性能（吞吐/延迟）

吞吐测试（iperf3）：

# Server
kubectl run iperf-server --image=networkstatic/iperf3 -- iperf3 -s -p 5201
# Client（跨节点）
kubectl run iperf-client --image=networkstatic/iperf3 --restart=Never -it -- \
  iperf3 -c iperf-server -p 5201 -t 60 -P 4

延迟/微秒级场景可补充 netperf；对比 Calico/Cilium 等网络插件在相同拓扑下的 P95/P99 延迟与吞吐量。

自动扩缩容（HPA）

示例：基于 CPU 70% 平均利用率扩缩容

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

验证指标：从触发到新 Pod Ready 的时间、扩容过程请求丢弃率、缩容优雅终止成功率。

五结果分析与优化闭环

指标与告警
- 建立 Prometheus 面板与告警：节点 CPU >85%、调度延迟**>500ms**、API Server P99 >1s；应用层关注 P95/P99 延迟、QPS、错误率。
深入诊断
- CPU 瓶颈：采集 kube-apiserver 火焰图
```
perf record -F 99 -p $(pgrep kube-apiserver) -g -- sleep 60
perf script | stackcollapse-perf.pl | flamegraph.pl > apiserver.svg
```
- 链路追踪：部署 Jaeger/OTel，定位关键路径 N+1 查询、慢外部依赖等。
优化与回归
- 调度优化：TopologySpreadConstraints、亲和/反亲和、污点容忍；资源配额 ResourceQuota；CNI/存储插件选择与参数调优；滚动更新策略与优雅终止超时。
- 回归测试：相同 SLO 下重复 Clusterloader2/k6 基线测试，验证优化有效性。

最新问答

相关标签