Kubernetes Pod 资源争用排查实战

Kubernetes Pod 资源争用排查实战

最近遇到一个线上问题：部署在 K8s 集群里的几个微服务，每到流量高峰期就出现偶发性超时，但监控面板上的 CPU 和内存指标都在正常范围内。排查了一圈，发现问题出在 Pod 之间的资源争用上。这篇文章记录一下完整的排查过程和思路。

一、症状

现象很诡异：Pod A 和 Pod B 调度在同一台 Node 上，A 是 CPU 密集型（数据处理），B 是 IO 密集型（网关转发）。高峰期 B 的 P99 延迟从 50ms 飙升到 2s，但 B 的 CPU 使用率只有 30%。单独看每个 Pod 的指标都很健康。

二、排查步骤

1. 确认 Pod 分布

先看这些 Pod 跑在哪里：

kubectl get pods -n production -o wide | grep -E "service-a|gateway-b"

发现 A 和 B 确实在同一台 Node 上。初步怀疑是“吵闹邻居”问题。

2. 查看 Node 层面指标

Pod 级别的 metrics 正常不代表 Node 级别没问题：

kubectl top node worker-node-3

Node CPU 到了 85%，但还没触发驱逐阈值。关键是看 CPU throttling：

kubectl top pod --containers -n production | grep gateway-b

果然，B 的容器虽然在 requests/limits 范围内，但 /sys/fs/cgroup/cpu.stat 里的 nr_throttled 计数器在快速增长。这说明容器被 Linux CFS 频繁限流了。

3. 检查 CPU 限流详情

用 cadvisor 暴露的 metrics 或者直接进 Node 查看 cgroup：

cat /sys/fs/cgroup/cpu/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod<uid>.slice/cpu.stat

也可以用 Prometheus 查：

rate(container_cpu_cfs_throttled_seconds_total{pod=~"gateway-b.*"}[5m])

4. 根因分析

问题链条是这样的：

• Pod A 配置了 CPU limit = 2 核，但实际是批处理任务，CPU 使用总是顶着 2 核跑
• Node 有 8 核，总共 7 个 Pod，sum(limits) 接近 8 核
• Linux CFS 给每个 cgroup 分配的时间片是按比例分配的，当核心被多个 cgroup 竞争时，IO 密集型的 B 即使 CPU 需求很小，也会因为 CFS 的公平调度而得不到及时响应
• B 的请求需要快速处理，但如果恰好在 A 抢占 CPU 的时间窗口内到达，B 的线程就得排队等调度

5. 解决方案

短期——打散 Pod 分布，加反亲和：

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        labelSelector:
          matchLabels:
            app: service-a
        topologyKey: kubernetes.io/hostname

中长期——合理设置 requests 和 limits：

resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
  limits:
    cpu: "1000m"
    memory: "1Gi"

关键点：requests 用于调度决策，limits 用于 CFS 限流。IO 密集型服务不要设太低 requests。

6. 效果验证

echo "GET http://gateway-b/api/health" | vegeta attack -duration=30s -rate=100 | vegeta report

修复前 P99 2340ms → 修复后 P99 78ms。

三、总结

• 不要只看 Pod 层面的指标，Node 层的 CPU throttling 同样重要
• CPU limits 对 IO 密集型服务可能适得其反
• 请求用 request 做软规划，用 limit 做硬限制
• 监控里加 container_cpu_cfs_throttled_seconds_total