3、核心指标定义(上):QPS、并发连接数(CCU)、请求延迟(P99/P95)、错误率(5xx)
网关容量规划的核心在于建立可量化的基线。在 K8s 集群升级场景中,网关(Ingress/Gateway API/Service Mesh 入口)是流量入口,其容量直接决定升级期间业务是否受损。本节定义四个最关键的容量指标:QPS、并发连接数(CCU)、请求延迟(P99/P95)、错误率(5xx)。这四个指标构成网关容量评估的“四象限”,缺一不可。
核心原则:容量基线不是单一数字,而是“在满足延迟和错误率约束下的最大 QPS 与 CCU 组合”。升级前必须同时采集这四类指标,才能判断网关是否处于健康水位。
3.1 QPS(每秒查询数)
QPS 是最直观的吞吐量指标,定义网关每秒能处理的请求数量。在 K8s 网关场景下,需区分总 QPS 与 有效 QPS:
- 总 QPS:网关 Pod 所有 Ingress/Route 规则接收的 HTTP 请求总数(含重试、健康检查)。
- 有效 QPS:剔除 4xx/5xx 错误后的成功请求数,反映真实业务承载能力。
| 维度 | 采集方式 | Prometheus 指标示例 | 升级前基线参考 |
|---|---|---|---|
| 总 QPS | 网关 Pod 级别 rate() 聚合 | rate(nginx_ingress_controller_requests[1m]) |
峰值不超过单 Pod 上限的 70% |
| 有效 QPS | 过滤 status < 500 | rate(nginx_ingress_controller_requests{status!~"5.."}[1m]) |
不低于总 QPS 的 95% |
| 单 Pod QPS | 除以副本数 | avg by (pod) (rate(...)) |
各 Pod 间偏差 < 20% |
升级前检查点:如果总 QPS 已接近网关 Pod 的 CPU 瓶颈(通常 CPU > 80% 时 QPS 增长曲线变平),必须先扩容再升级,否则升级过程中 Pod 滚动重启会导致容量骤降。
3.2 并发连接数(CCU)
CCU(Concurrent Connections)衡量网关同时维持的 TCP/HTTP 连接数。K8s 网关通常使用反向代理模式(如 Nginx、Envoy),每个连接会占用内存和文件描述符。CCU 过高会导致连接超时、内存 OOM 或端口耗尽。
需要区分两类连接:
- 活跃连接(Active Connections):正在处理请求的连接,直接消耗 CPU 和内存。
- 空闲连接(Idle Connections):Keep-Alive 保持的空闲连接,主要消耗内存和文件句柄。
# Nginx Ingress 连接数 PromQL 示例
# 当前活跃连接数
nginx_ingress_controller_nginx_process_connections{state="active"}
# 当前空闲连接数
nginx_ingress_controller_nginx_process_connections{state="idle"}
# 总连接数(活跃 + 空闲)
sum(nginx_ingress_controller_nginx_process_connections) by (pod)
| 连接类型 | 影响资源 | 升级前警戒线 | 扩容建议 |
|---|---|---|---|
| 活跃连接 | CPU、内存、请求队列 | 单 Pod 活跃连接 > 5000 | 增加副本数或调大 worker_connections |
| 空闲连接 | 内存、文件描述符 | 空闲连接占比 > 60% | 缩短 keepalive_timeout |
| 总连接数 | 系统 ulimit 限制 | 接近 Pod 文件描述符上限的 80% | 调整 fs.file-max 或增加 Pod 资源 |
常见陷阱:升级过程中,旧 Pod 被逐步销毁,新 Pod 尚未完全就绪,会导致剩余 Pod 的 CCU 瞬间飙升。如果升级前 CCU 已处于高水位(>70% 上限),升级期间极易触发连接拒绝(Connection Refused)错误。建议升级前将 CCU 控制在 50% 以下。
3.3 请求延迟(P99/P95)
延迟是容量规划的“软约束”。即使 QPS 和 CCU 都在范围内,如果延迟大幅增加,说明网关已进入过载状态。P99(99% 请求的延迟上限)和 P95(95% 请求的延迟上限)是最常用的尾延迟指标。
- P99:代表最差情况下的用户体验,通常用于 SLA 承诺。
- P95:代表大多数用户的体验,比 P99 更稳定,受极端值影响小。
# Nginx Ingress 延迟 PromQL(分位数)
# P99 延迟(毫秒)
histogram_quantile(0.99,
sum(rate(nginx_ingress_controller_request_duration_seconds_bucket[1m])) by (le))
# P95 延迟(毫秒)
histogram_quantile(0.95,
sum(rate(nginx_ingress_controller_request_duration_seconds_bucket[1m])) by (le))
| 延迟分位 | 典型基线(内部服务) | 典型基线(外部 API) | 升级前异常信号 |
|---|---|---|---|
| P50 | < 10ms | < 50ms | P50 翻倍 |
| P95 | < 50ms | < 200ms | P95 超过 500ms |
| P99 | < 200ms | < 500ms | P99 超过 1s 或持续抖动 |
延迟与容量的关系:当 QPS 接近网关瓶颈时,P99 会率先出现“拐点”——延迟急剧上升,而 QPS 增长趋缓。这个拐点就是容量上限。升级前应找到当前集群的“延迟拐点 QPS”,作为升级期间的保护阈值。
3.4 错误率(5xx)
错误率是容量规划的“硬红线”。5xx 错误(服务端错误)直接表明网关或后端服务已无法正常处理请求。升级前必须建立 5xx 错误率的基线,并区分网关层错误与后端服务错误。
- 网关层 5xx:502 Bad Gateway(后端不可达)、503 Service Unavailable(限流/熔断)、504 Gateway Timeout(上游超时)。
- 后端服务 5xx:500 Internal Server Error(后端代码异常),通常由网关透传。
# 5xx 错误率 PromQL
# 网关层 5xx 占比
sum(rate(nginx_ingress_controller_requests{status=~"5.."}[1m]))
/
sum(rate(nginx_ingress_controller_requests[1m])) * 100
# 按状态码细分
rate(nginx_ingress_controller_requests{status="502"}[1m])
rate(nginx_ingress_controller_requests{status="503"}[1m])
rate(nginx_ingress_controller_requests{status="504"}[1m])
| 错误类型 | 常见原因 | 升级前基线 | 升级期间容忍上限 |
|---|---|---|---|
| 502 | 后端 Pod 未就绪、Service 端点为空 | < 0.1% | < 0.5%(滚动升级期间) |
| 503 | 网关限流、后端熔断、Pod 资源不足 | < 0.05% | < 0.2% |
| 504 | 后端响应超时、网关与后端网络延迟增加 | < 0.1% | < 0.3% |
| 500 | 后端代码异常(非网关问题) | < 0.5% | < 1.0% |
升级前必须执行:在测试环境模拟升级过程(Pod 滚动重启),观察 5xx 错误率的变化。如果模拟升级期间 5xx 超过 0.5%,说明当前网关容量或优雅终止配置不足,必须优化后再进行生产升级。
3.5 指标采集与基线记录
升级前至少采集 7 天 的上述四类指标,记录每日峰值和 P99 值,形成基线表。以下是一个基线记录模板:
# 基线记录示例(JSON 格式)
{
"cluster": "prod-eks-1",
"gateway": "nginx-ingress",
"采集周期": "2025-03-01 ~ 2025-03-07",
"baseline": {
"qps": {
"peak": 12500,
"avg": 7800,
"单Pod上限": 3000
},
"ccu": {
"active_peak": 4200,
"idle_peak": 1800,
"total_peak": 6000,
"单Pod上限": 8000
},
"latency_ms": {
"p50": 8,
"p95": 35,
"p99": 120
},
"error_rate_5xx": {
"502": 0.03,
"503": 0.01,
"504": 0.02,
"500": 0.15
}
},
"升级前水位": "安全(均低于70%阈值)"
}
自动化建议:将上述基线记录写入 ConfigMap 或 Prometheus 的 recording rules,升级前自动比对当前指标与基线。如果当前指标超过基线的 1.2 倍,触发告警并阻止升级流程。