CentOS上如何进行Kubernetes的性能测试 - 问答

在 CentOS 上进行 Kubernetes 性能测试

一、目标与范围

明确你要验证的SLI/SLO：例如控制面 API 延迟、调度吞吐、Pod 启动延迟、etcd 健康与 IO、节点资源利用率等，这些指标直接影响业务体验与稳定性。
测试类型分层：
- 基础设施基线（节点 CPU/内存/磁盘/网络）
- Kubernetes 控制面与调度（API 响应、调度吞吐、Pod 启动延迟）
- 应用层吞吐与稳定性（HTTP 长稳压测、HPA 弹性）
规模与场景：是否需要做大规模模拟（少量机器模拟成千上万 Node/Pod），还是仅做中小规模压测与回归。
以上做法与指标框架与社区实践一致，可据此制定你的测试目标与验收标准。

二、环境与工具准备

节点与系统：在 CentOS 上准备至少 1–3 台 Master（生产建议 3 台）与若干 Worker，内核与容器运行时按官方/发行版建议版本配置；确保节点间网络与 DNS 正常。
观测与压测组件：
- 指标采集与展示：Prometheus + Grafana（抓取 apiserver、scheduler、kubelet、etcd、节点资源等）。
- 负载与伸缩：k6/wrk/ab（HTTP 压测）、HPA（基于 CPU/自定义指标）。
- 集群性能框架：perf-tests/clusterloader2（官方可扩展性与性能测试框架，覆盖 API 响应、调度吞吐、Pod 启动延迟、etcd 指标等）。
- 大规模模拟：kubemark（Hollow Node 模拟器，用少量机器模拟大规模集群）。
  这些工具是进行 Kubernetes 性能与可扩展性测试的通用组合。

三、快速验证流程（功能与基线）

集群就绪：
- 检查节点状态：kubectl get nodes 均为 Ready。
- 检查核心组件：kubectl get pods -n kube-system 运行正常。
部署测试应用：
- 部署 Nginx：kubectl create deployment nginx --image=nginx --replicas=3
- 暴露服务：kubectl expose deployment nginx --type=NodePort --port=80
- 访问验证：curl http://<任一节点IP>:<NodePort> 返回 Nginx 欢迎页。
伸缩与自愈：
- 扩容：kubectl scale deployment nginx --replicas=5
- 自愈：删除一个 Pod，观察 Deployment 自动重建。
基线性能采集：
- 资源使用：kubectl top nodes、kubectl top pods
- 事件与日志：kubectl describe pod <pod>，kubectl logs <pod>
  以上步骤可快速验证集群可用性与基本伸缩/自愈能力，为后续压测建立基线。

四、控制面与调度性能测试（clusterloader2）

测试思路：用 clusterloader2 按“策略 + 覆盖配置”运行，自动创建负载、采集指标并生成报告。

运行示例（示例变量需按你的环境替换）：

# 1) 编译
git clone https://github.com/kubernetes/perf-tests
cd perf-tests/clusterloader2 && go build -o clusterloader ./cmd/

# 2) 环境变量（示例）
export KUBE_CONFIG=$HOME/.kube/config
export PROVIDER=local
export TEST_CONFIG=configs/examples/density/config.yaml
export REPORT_DIR=./reports
export LOG_FILE=logs/run.log

# 3) 执行
./clusterloader \
  --kubeconfig=$KUBE_CONFIG \
  --provider=$PROVIDER \
  --testconfig=$TEST_CONFIG \
  --report-dir=$REPORT_DIR \
  --alsologtostderr 2>&1 | tee $LOG_FILE

关键指标与输出：
- APIResponsiveness / APIAvailability：apiserver 延迟与可用性。
- SchedulingThroughput / SchedulingMetrics：调度吞吐与调度相关指标。
- PodStartupLatency：Pod 启动阶段与 E2E 耗时（常见输出如 p50/p90/p99）。
- EtcdMetrics / ResourceUsageSummary：etcd 健康与资源使用汇总。
- 报告与日志位于 $REPORT_DIR，便于对比不同规模/参数下的性能变化。
  该流程覆盖社区常用的密度与吞吐测试场景，可直接用于回归与容量评估。

五、大规模模拟与弹性场景（kubemark + HPA）

大规模模拟（kubemark）：
- 原理：在“外部集群”运行 Hollow Node（阉割版 kubelet），在“被测集群”注册为 Node，从而用少量机器模拟成千上万 Node/Pod 的规模。
- 基本步骤：
  - 标记真实 Node（避免压测 Pod 落到真实 Node）：
    - kubectl taint nodes <node> role=real:NoSchedule
    - kubectl label nodes <node> role=real
  - 准备 kubeconfig Secret（供 Hollow Node 使用）。
  - 部署 kubemark Pod/配置，使其对接被测集群 API。
  - 在“被测集群”上运行 clusterloader2，对“模拟的大规模集群”发起密度/吞吐等测试。
- 适用场景：验证控制面在大规模下的 API 延迟、调度吞吐、Pod 启动延迟 等指标是否达标。

弹性与稳定性（HPA + 应用压测）：

部署 HPA（示例为 CPU 50%）：

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

压测触发弹性：k6 run script.js 或 wrk -t12 -c400 -d60s http://<svc>/，观察 HPA 扩缩容、Pod 启动延迟与成功率。

观测与验收：
- 建议以 Prometheus + Grafana 持续采集控制面与节点指标，围绕你定义的 SLI/SLO 进行阈值验收（如读/写 API 延迟阈值、Pod 启动 p95/p99 阈值等）。
  kubemark 能在有限硬件下模拟大规模集群，配合 HPA 与应用压测可验证弹性与稳定性。

0 赞

0 踩