4. 性能压测基础理论：容量、吞吐量、延迟、并发、QPS/TPS、资源利用率、SLA/SLO 定义

在 Kubernetes 环境进行容量规划与性能压测之前，必须建立一套统一的度量体系。本章将定义压测领域的七个核心概念，并解释它们之间的数学关系与工程约束。这些指标是后续巡检脚本编排、故障排查与容量评估的量化基础。

4.1 核心指标定义与对比

下表从定义、单位、典型场景三个维度对比七个核心指标，帮助建立清晰的认知边界：

4.2 指标间的数学关系与压测模型

理解指标间的依赖关系是设计压测场景的前提。以下公式与模型是编排巡检脚本时的计算基础：

• Little's Law（利特尔法则）： 并发数 = 吞吐量 × 平均延迟。在 K8s 环境中，该公式用于估算维持目标吞吐量所需的 Pod 副本数。
• 资源利用率与容量： 容量上限 = 资源总量 × 目标利用率阈值。例如，集群总 CPU 为 100 核，目标利用率阈值为 75%，则有效容量为 75 核。
• SLO 违约点： 当 实际延迟 > SLO 延迟阈值 或 实际可用性 < SLO 可用性目标 时，触发容量告警。

# 压测脚本中常用的容量估算逻辑（伪代码）
total_cpu = sum(node_cpu_capacity)
target_utilization = 0.75
effective_capacity = total_cpu * target_utilization

# 根据单 Pod 平均 CPU 消耗计算最大副本数
pod_cpu_avg = 0.5  # 核
max_replicas = int(effective_capacity / pod_cpu_avg)
print(f"集群有效容量: {effective_capacity} 核, 最大副本数: {max_replicas}")

4.3 延迟分布与百分位指标

平均延迟（Avg Latency）具有欺骗性，在压测中必须关注延迟分布。K8s 巡检脚本通常采集以下百分位：

• P50（中位数）： 代表典型用户体验。
• P95： 代表 5% 的慢请求，常用于排查尾部延迟。
• P99： 代表 1% 的最慢请求，是 SLO 的常见锚点。
• P999： 代表 0.1% 的极端延迟，通常由 GC、网络抖动或资源争抢引起。

4.4 容量、吞吐量与延迟的三角关系

下图展示了在固定资源条件下，容量、吞吐量与延迟之间的典型非线性关系。这是压测脚本编排时判断系统是否进入“过载区”的依据。

4.5 SLA 与 SLO 的工程定义

在 K8s 巡检与压测中，SLA 和 SLO 是判断系统是否“健康”的最终标准。两者区别如下：

4.6 压测指标在 K8s 巡检脚本中的映射

将上述理论指标映射到 K8s 巡检脚本的实际采集点，是编排自动化巡检的关键步骤：

• 容量： 通过 kubectl describe node 获取 allocatable 资源，结合 kubectl top pod 计算剩余容量。
• 吞吐量： 通过 Prometheus 查询 rate(http_requests_total[1m]) 或 Ingress Controller 的 nginx_ingress_controller_requests 指标。
• 延迟： 使用 histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) 计算 P99 延迟。
• 并发： 通过 kubectl get pods --field-selector=status.phase=Running | wc -l 统计运行中 Pod 数，或通过 Service Monitor 采集活跃连接数。
• 资源利用率： 使用 kubectl top node 或 Prometheus node_cpu_seconds_total 指标。
• SLO 合规： 在巡检脚本中定义 slo_budget 变量，计算滚动窗口内的错误预算消耗。

# 巡检脚本片段：采集并判断 SLO 合规性
#!/bin/bash
# 依赖：Prometheus API 或 kubectl

P99_THRESHOLD=200  # ms
ERROR_RATE_THRESHOLD=0.001  # 0.1%

# 采集 P99 延迟（示例使用 PromQL）
P99_LATENCY=$(curl -s 'http://prometheus:9090/api/v1/query?query=histogram_quantile(0.99, ...)' | jq -r '.data.result[0].value[1]')

# 采集错误率
ERROR_RATE=$(curl -s 'http://prometheus:9090/api/v1/query?query=sum(rate(http_requests_total{status=~"5.."}[5m]))/sum(rate(http_requests_total[5m]))' | jq -r '.data.result[0].value[1]')

# SLO 判断
if (( $(echo "$P99_LATENCY > $P99_THRESHOLD" | bc -l) )); then
  echo "SLO 违规: P99 延迟 ${P99_LATENCY}ms 超过阈值 ${P99_THRESHOLD}ms"
fi

if (( $(echo "$ERROR_RATE > $ERROR_RATE_THRESHOLD" | bc -l) )); then
  echo "SLO 违规: 错误率 ${ERROR_RATE} 超过阈值 ${ERROR_RATE_THRESHOLD}"
fi

4.7 压测场景编排的指标选择原则

在编排压测场景时，并非所有指标都需要同时监控。以下原则帮助聚焦关键度量：

1. 面向 SLO 选指标： 每个压测场景必须绑定至少一个 SLO 指标（如 P99 延迟或错误率），作为通过/失败判据。
2. 容量测试关注资源利用率： 容量压测时，以 CPU/内存利用率 80% 作为停止条件，而非等到延迟爆炸。
3. 吞吐量测试关注拐点： 逐步增加并发，记录吞吐量变化曲线，找到“吞吐量不再随并发增加而线性增长”的拐点。
4. 延迟测试关注尾部： 在低并发下先验证 P50 延迟基线，再在高并发下观察 P99 和 P999 的偏移量。
5. 巡检脚本使用滚动窗口： 避免单点采样，使用 5 分钟或 10 分钟的滑动窗口计算指标，减少毛刺干扰。