3. 资源争抢场景分析：CPU、内存、磁盘IO争抢的典型表现与根因
在 Kubernetes 多租户或混部场景中，多个 Pod 共享同一 Node 的计算与存储资源。当资源预留不足或 Limit 配置不合理时，Pod 之间会发生资源争抢，导致服务质量下降、延迟飙升甚至 Pod 被驱逐。本章从 CPU、内存、磁盘 IO 三个维度，分析争抢的典型表现与根因。
3.1 CPU 争抢：节流与调度延迟
CPU 是可压缩资源，争抢时不会直接杀死 Pod，但会导致 CPU Throttling（节流）和调度延迟增加。
| 典型表现 | 监控指标 | 根因 |
|---|---|---|
| 应用响应时间增加，但 CPU 使用率未达 100% | container_cpu_cfs_throttled_seconds_total |
CPU Limit 设置过低，CFS 配额周期内被限流 |
| Pod 启动变慢，就绪检查超时 | node_cpu_seconds_total 各 mode 占比 |
Node 上 CPU 密集型 Pod 过多，内核调度器无法及时分配时间片 |
| 相同 Request 的 Pod 性能差异大 | 容器级别 CPU 使用率与 Limit 比值 | CPU 亲和性设置不当或 NUMA 节点间资源不均衡 |
关键结论： CPU 争抢的根因通常是 Limit 设置过紧 或 Request 与 Limit 差距过大（Burstable QoS 导致节流）。建议为延迟敏感型业务设置 CPU Request = Limit，使用 Guaranteed QoS。
3.2 内存争抢：OOM 与驱逐
内存是不可压缩资源，一旦超过 Limit 或 Node 内存不足，会直接触发 OOM Kill 或 Pod 驱逐。
| 典型表现 | 监控指标 | 根因 |
|---|---|---|
| Pod 突然重启，Exit Code 137 | container_oom_events_total |
容器内存使用超过 Limit，被 cgroup OOM Killer 杀死 |
| Node 状态为 MemoryPressure，部分 Pod 被驱逐 | node_memory_MemAvailable_bytes 低于阈值 |
Node 上所有 Pod 内存总和超过 Node 容量，kubelet 触发驱逐 |
| 应用出现频繁 GC 或 Swap 使用（已禁用） | 容器 RSS 持续增长，接近 Limit | 内存泄漏或业务突发流量导致内存需求超出预期 |
避坑提示： 不要在生产环境设置
memory.swappiness 为非零值。Kubernetes 默认禁用 Swap，开启 Swap 会导致 QoS 失效，OOM 行为不可预测。
3.3 磁盘 IO 争抢：吞吐与延迟抖动
磁盘 IO 是 不可压缩 但 可隔离 的资源。Kubernetes 原生不提供 IO 隔离，争抢时表现为吞吐下降和延迟抖动。
| 典型表现 | 监控指标 | 根因 |
|---|---|---|
| 日志写入延迟高，应用阻塞在 IO | node_disk_io_time_seconds_total 升高 |
多个 Pod 同时写日志或写本地临时卷，磁盘队列深度过大 |
| 数据库 Pod 查询变慢，但 CPU 和内存正常 | container_fs_io_current 持续高位 |
同一 Node 上存在大量 IO 密集型 Pod（如数据管道、ETL） |
| Pod 启动超时，镜像拉取慢 | 镜像层解压时间 > 预期 | 磁盘带宽被其他 Pod 占用，导致镜像层写入慢 |
推荐实践： 使用本地 SSD 或云盘时，为高 IO 应用设置
emptyDir.medium: Memory 或使用 PV 的 IOPS 限速（如 AWS EBS 的 volumeIOPS）。对于关键业务，考虑使用 cgroup v2 IO Controller 或第三方 IO 隔离方案。
3.4 三种资源争抢的对比与根因总结
| 资源类型 | 是否可压缩 | 争抢后果 | 典型根因 | 推荐修复方向 |
|---|---|---|---|---|
| CPU | 是 | 节流、延迟增加 | Limit 过小 / Burstable QoS | 设置 CPU Request = Limit |
| 内存 | 否 | OOM Kill / Pod 驱逐 | Limit 超限 / 内存泄漏 | 设置合理 Limit + 垂直扩缩容 |
| 磁盘 IO | 否（可隔离） | 吞吐下降 / 延迟抖动 | IO 密集型 Pod 混部 / 无 IO 限制 | 使用 PV IOPS 限速 / 专用节点池 |
3.5 实战排查命令速查
当怀疑资源争抢时，按以下顺序快速定位根因：
- 检查 Pod 事件：
kubectl describe pod <pod-name>查看 OOM、驱逐、节流事件。 - 查看容器指标： 使用
kubectl top pod对比 Request/Limit 使用率。 - 分析 CPU 节流： 进入容器执行
cat /sys/fs/cgroup/cpu/cpu.stat查看nr_throttled值。 - 检查磁盘 IO： 在 Node 上执行
iostat -x 1观察await和%util。 - 确认 QoS 等级：
kubectl get pod <pod-name> -o yaml | grep qosClass。
核心原则： 资源争抢的根因往往不是单一 Pod 的问题，而是 调度策略 + 资源配额 + 混部密度 三者失衡的结果。在排查时，始终从 Node 视角出发，先看整体资源水位，再定位具体 Pod。