4. 核心指标定义(下):吞吐量(bps)、CPU/内存利用率、Pod 原地重启次数、OOMKill 频率
上一节定义了连接与请求维度的指标,本节继续完成网关容量基线的另一组核心指标:吞吐量(bps)、CPU/内存利用率、Pod 原地重启次数与OOMKill 频率。这四个指标分别从网络带宽消耗、资源饱和度、进程稳定性三个层面刻画网关的承载极限与健康边界。
4.1 吞吐量(bps)—— 带宽消耗基线
吞吐量指网关在单位时间内处理的网络数据量,通常以 bps(bits per second) 或 Bps(Bytes per second) 计量。在 K8s 环境中,网关 Pod 的吞吐量受限于节点带宽、CNI 插件性能、Service 封装开销以及 Pod 自身的网络栈处理能力。
| 吞吐量类型 | 定义 | 采集来源 | 升级前关注点 |
|---|---|---|---|
| 入站吞吐量 | 网关 Pod 接收的流量速率 | Pod 网络监控(cAdvisor / eBPF) | 是否接近节点带宽上限 |
| 出站吞吐量 | 网关 Pod 发送的流量速率 | Pod 网络监控(cAdvisor / eBPF) | 是否存在回源带宽瓶颈 |
| 有效吞吐量 | 去除重传、协议开销后的净数据速率 | 应用层指标 + 网络抓包 | 反映真实业务承载能力 |
基线建议:升级前应记录网关 Pod 在峰值业务时段的最大入站/出站吞吐量,并对比节点带宽的 60% 作为安全阈值。若吞吐量超过节点带宽的 70%,升级期间应优先扩容或迁移至带宽更大的节点池。
4.2 CPU / 内存利用率 —— 资源饱和度基线
CPU 和内存利用率是判断网关 Pod 是否处于健康资源区间的直接指标。升级过程中,控制面组件(如 kube-apiserver、kube-controller-manager)的负载变化可能间接影响网关 Pod 的资源调度与抢占行为。
- CPU 利用率:建议以 Pod 的
requests.cpu为基准,记录 P50 / P95 / P99 分位的 CPU 使用率。升级前若 P99 利用率超过 80%,说明网关已接近计算瓶颈,升级期间可能因调度延迟导致请求超时。 - 内存利用率:关注
container_memory_working_set_bytes与limits.memory的比值。当内存利用率持续超过 85% 时,GC 频率升高,响应延迟抖动加剧。 - 资源争抢风险:若多个网关 Pod 共享同一节点,需额外关注节点级别的 CPU 和内存压力,避免升级期间因 Pod 重调度引发资源超分。
关键阈值速查:
CPU P99 利用率 < 75% → 安全区
CPU P99 利用率 75% ~ 85% → 关注区,升级前建议扩容
CPU P99 利用率 > 85% → 风险区,必须扩容或优化后再升级
内存利用率 < 70% → 安全区
内存利用率 70% ~ 85% → 关注区
内存利用率 > 85% → 风险区
CPU P99 利用率 < 75% → 安全区
CPU P99 利用率 75% ~ 85% → 关注区,升级前建议扩容
CPU P99 利用率 > 85% → 风险区,必须扩容或优化后再升级
内存利用率 < 70% → 安全区
内存利用率 70% ~ 85% → 关注区
内存利用率 > 85% → 风险区
4.3 Pod 原地重启次数 —— 进程稳定性基线
Pod 原地重启(CrashLoopBackOff / 主动重启)次数直接反映网关进程的稳定性。升级前若 Pod 频繁重启,说明网关存在内存泄漏、配置错误或依赖故障,升级操作可能进一步放大这些隐患。
| 重启类型 | 常见原因 | 升级前处理策略 |
|---|---|---|
| OOMKill 重启 | 内存超限、内存泄漏 | 增大 limits.memory 或排查泄漏 |
| 存活探针失败重启 | 死锁、goroutine 泄漏、端口未监听 | 修复探针逻辑或增加超时 |
| 配置热加载失败重启 | 配置格式错误、证书过期 | 验证配置并回滚至稳定版本 |
| 主动滚动重启 | 版本更新、配置变更 | 记录重启次数,排除在基线外 |
基线规则:升级前 7 天内,每个网关 Pod 的原地重启次数应 < 2 次(排除主动滚动重启)。若超过该阈值,必须定位根因并修复,否则升级期间可能引发级联故障。
4.4 OOMKill 频率 —— 内存边界基线
OOMKill(Out Of Memory Killer)是 Linux 内核在系统内存不足时强制终止进程的机制。在 K8s 环境中,当 Pod 的内存使用超过 limits.memory 或节点内存不足时,Pod 内的进程可能被 OOM Killer 杀死。OOMKill 频率是衡量网关内存配置是否合理的关键信号。
- 采集方式:通过
kubectl describe pod查看Last State中的Reason: OOMKilled,或通过container_oom_events_total指标(需启用 cAdvisor 或 eBPF 监控)。 - 频率计算:统计过去 24 小时内每个网关 Pod 的 OOMKill 次数。若任意 Pod 的 OOMKill 频率 > 0,说明内存限制过紧或存在内存泄漏。
- 升级影响:升级过程中,控制面组件可能短暂增加网关 Pod 的内存开销(如配置重载、证书轮换),若内存余量不足,极易触发 OOMKill。
基线建议:升级前应确保所有网关 Pod 在 72 小时内 OOMKill 次数为 0。若存在 OOMKill 记录,建议将
limits.memory 提升 20%~30% 并观察 24 小时,确认无新 OOMKill 后再执行升级。
4.5 四维指标联动分析
吞吐量、CPU/内存利用率、Pod 重启次数、OOMKill 频率并非孤立指标,它们之间存在强关联。下图展示了四维指标在网关容量评估中的联动关系:
4.6 指标采集与基线验证流程
在升级前,建议按以下步骤完成四维指标的采集与基线验证:
- 数据采集:使用 Prometheus + cAdvisor 采集过去 7 天的网关 Pod 网络、CPU、内存指标,以及
kube_pod_container_status_restarts_total和container_oom_events_total。 - 基线计算:按业务高峰时段(如 10:00-12:00、14:00-16:00)计算各指标的 P95 / P99 值,并与上述阈值对比。
- 异常标记:标记超出阈值的 Pod 和节点,生成风险清单。
- 修复与验证:对风险项进行扩容、配置调整或代码修复,重新采集 24 小时数据确认指标回归安全区。
- 基线冻结:在升级窗口前 48 小时冻结网关配置与资源分配,避免基线漂移。
实践提示:建议将上述基线指标写入
ConfigMap 或 PrometheusRule,在升级前自动触发告警。例如:groups:
- name: gateway_capacity_baseline
rules:
- alert: GatewayMemoryHigh
expr: (container_memory_working_set_bytes{container="gateway"} / on(container) kube_pod_container_resource_limits{resource="memory"}) > 0.85
for: 5m
labels:
severity: warning
annotations:
summary: "网关 Pod {{ $labels.pod }} 内存利用率超过 85%"