3. 性能瓶颈分析框架：USE 与 RED 方法在 K8s 中的应用
在多租户 Kubernetes 集群中，性能瓶颈的定位不能依赖直觉或随机排查。我们需要一套系统化的方法论来指导监控指标的采集、分析与决策。本章将深入讲解两种业界公认的瓶颈分析框架——USE 方法（Utilization、Saturation、Errors）与 RED 方法（Rate、Errors、Duration），并展示它们在 K8s 多租户场景下的具体落地方式。
3.1 USE 方法：资源视角的瓶颈定位
USE 方法由 Brendan Gregg 提出，专注于资源层面。对于每一个资源（CPU、内存、网络、磁盘、Pod 等），我们依次检查三个核心指标：
- 利用率（Utilization）：资源被占用的平均百分比。高利用率意味着资源接近饱和，但需要结合饱和度判断是否已产生排队。
- 饱和度（Saturation）：资源无法及时服务的额外请求量，通常表现为队列长度或等待时间。这是瓶颈的直接证据。
- 错误（Errors）：资源操作失败的次数或比例。错误可能由配置、硬件或软件缺陷引起，有时是瓶颈的间接信号。
USE 方法核心原则： 先检查利用率，再检查饱和度，最后检查错误。如果利用率高但饱和度低，说明资源尚有冗余；如果利用率和饱和度都高，则瓶颈明确；如果错误率异常，优先排查错误原因。
3.1.1 K8s 资源维度的 USE 指标映射
下表将 USE 方法映射到 K8s 多租户环境中最常见的资源对象：
| 资源类型 | 利用率指标 | 饱和度指标 | 错误指标 |
|---|---|---|---|
| Node CPU | node_cpu_utilization (avg over 1m) | node_load1 / node_cpu_count | node_cpu_throttled_seconds_total |
| Node 内存 | node_memory_MemTotal - node_memory_MemAvailable | node_memory_pressure (OOM events) | node_memory_errors_uncorrected_total |
| Node 磁盘 I/O | node_disk_io_time_seconds_total (rate) | node_disk_io_queue_depth | node_disk_io_errors_total |
| Node 网络 | node_network_receive_bytes_total (rate) / bandwidth | node_netstat_Tcp_RetransSegs (rate) | node_network_receive_errors_total |
| Pod CPU | container_cpu_usage_seconds_total (rate) / container_spec_cpu_quota | container_cpu_cfs_throttled_seconds_total | container_cpu_cfs_periods_total (throttled ratio) |
| Pod 内存 | container_memory_working_set_bytes / container_spec_memory_limit_bytes | container_memory_failures_total (OOM kill) | container_memory_failcnt |
实战提示： 在多租户场景下，建议为每个租户（Namespace）建立独立的 USE 仪表盘。重点关注
container_cpu_cfs_throttled_seconds_total 和 container_memory_failures_total，这两个指标直接反映资源限制是否过紧。
3.2 RED 方法：服务视角的瓶颈定位
RED 方法由 Tom Wilkie（Grafana Labs）提出，专注于服务层面。对于每一个微服务或 API 端点，我们检查三个核心指标：
- 速率（Rate）：每秒请求数（RPS）。反映服务的负载水平。
- 错误（Errors）：请求失败的比例（如 HTTP 5xx、gRPC 错误码）。反映服务的健康状态。
- 持续时间（Duration）：请求响应时间的分布（如 P50、P95、P99）。反映服务的性能表现。
RED 方法核心原则： 速率决定负载，错误决定可用性，持续时间决定体验。三者结合可以快速判断服务瓶颈是来自上游流量、自身处理能力还是下游依赖。
3.2.1 K8s 服务维度的 RED 指标映射
在 K8s 中，RED 方法通常通过 Service Mesh（如 Istio、Linkerd）或 Ingress Controller 暴露的指标实现：
| 指标维度 | Istio 指标示例 | Prometheus 查询 | 多租户标签 |
|---|---|---|---|
| 速率 (Rate) | istio_requests_total |
rate(istio_requests_total[1m]) |
source_workload_namespace, destination_service |
| 错误 (Errors) | istio_requests_total{response_code=~"5.."} |
sum(rate(istio_requests_total{response_code=~"5.."}[1m])) / sum(rate(istio_requests_total[1m])) |
response_code, destination_principal |
| 持续时间 (Duration) | istio_request_duration_milliseconds_bucket |
histogram_quantile(0.99, rate(istio_request_duration_milliseconds_bucket[5m])) |
destination_workload, request_protocol |
注意： 在多租户集群中，RED 指标必须按 Namespace 或 ServiceAccount 进行隔离。如果全局聚合，一个租户的突发流量会掩盖其他租户的瓶颈。建议在 Prometheus 中配置
namespace:.* 的 recording rules 来预聚合每个租户的 RED 数据。
3.3 USE 与 RED 的协同：从资源到服务的完整链路
USE 和 RED 并非互斥，而是互补。USE 回答“资源是否够用”，RED 回答“服务是否正常”。在 K8s 多租户环境中，瓶颈可能出现在任意一层，我们需要将两者串联起来形成诊断链路。
下图展示了从服务 RED 指标异常到资源 USE 指标排查的典型流程：
3.4 多租户场景下的 USE + RED 实践清单
在 K8s 多租户集群中实施 USE 和 RED 方法时，需要额外关注租户隔离与资源争抢。以下是经过验证的实践清单：
- 按租户建立指标视图：在 Grafana 中为每个 Namespace 创建独立的 USE 和 RED 仪表盘，使用
namespace标签过滤。 - 设置租户级告警阈值：不同租户的业务容忍度不同。例如，金融租户的 P99 告警阈值可能设为 200ms，而日志处理租户可设为 2s。
- 优先排查饱和度指标：在 USE 方法中，饱和度（如 CPU Throttling、内存 OOM、网络重传）是比利用率更敏感的瓶颈信号。
- 结合 RED 的 Duration 定位慢调用：如果某个租户的 P99 升高，先检查该租户依赖的下游服务 RED 指标，判断是自身问题还是下游瓶颈。
- 使用 Prometheus recording rules 预聚合：避免每次查询都扫描全量数据，尤其当集群规模超过 100 个节点时。
案例： 某 SaaS 平台发现租户 A 的 API 响应时间从 50ms 飙升至 2s。RED 检查显示速率未变，但 P99 恶化；USE 检查发现租户 A 所在 Node 的 CPU 利用率仅 40%，但
container_cpu_cfs_throttled_seconds_total 在租户 A 的 Pod 上持续增长。根因：租户 A 的 CPU Limit 设置过低（0.5 核），导致 CPU 节流。调整 Limit 至 1 核后，P99 恢复至 60ms。
3.5 两种方法的对比与选择
| 维度 | USE 方法 | RED 方法 |
|---|---|---|
| 关注对象 | 资源（Node、Pod、网络、磁盘） | 服务（微服务、API、数据库连接） |
| 核心指标 | 利用率、饱和度、错误 | 速率、错误、持续时间 |
| 适用场景 | 基础设施瓶颈、资源争抢、容量规划 | 服务性能退化、用户体验、SLA 监控 |
| 典型工具 | Node Exporter、cAdvisor、Prometheus | Istio、Linkerd、Ingress Nginx、Kiali |
| 多租户适配 | 按 Namespace 聚合资源使用 | 按 Namespace 和 ServiceAccount 聚合请求 |
| 瓶颈定位速度 | 快（直接看饱和度） | 快（直接看 Duration 和 Errors） |
推荐策略： 日常监控以 RED 为主（服务健康），故障排查时先 RED 后 USE（从服务到资源）。在 K8s 多租户环境中，建议将 RED 作为第一响应层，USE 作为根因分析层。