主流资源类型：CPU、内存、GPU、存储与网络

做资源配额动态调整，第一步得搞清楚——你到底在调什么？

很多人一上来就写 YAML，配 LimitRange，结果 Pod 跑不起来才发现，连资源类型都没对齐。我见过不少团队，CPU 和内存配得挺细，但 GPU 和网络带宽完全没管，最后模型训练任务把集群打爆了。

这一章，我把主流资源类型掰开揉碎讲清楚。你想想看，只有知道每种资源的特性，才能设计出合理的动态策略。

核心观点：资源配额不是「配完就完」，而是要根据业务负载、硬件特性、调度策略持续调整。每种资源都有自己的「脾气」。

2.1 CPU：可压缩资源，但别滥用

CPU 是典型的可压缩资源。什么意思？说白了，你给 Pod 申请了 2 核，但它实际只用了 1 核，剩下的核可以被其他 Pod 抢走。反过来，如果它想用 3 核，但 Limit 设了 2 核，那就只能等着。

我个人习惯把 CPU 的 Request 设得保守一点，Limit 设得宽松一点。为什么？因为 CPU 是时间片轮转的，超卖一点问题不大。但要注意——超卖太多会导致 CPU Throttling，应用响应变慢。

经验之谈：我在项目中遇到过，某个 Java 服务 CPU Request 设了 0.5 核，Limit 设了 4 核。结果高峰期 CPU 被打满，容器频繁 Throttle，接口延迟从 10ms 飙到 500ms。后来把 Request 调到 2 核，Limit 保持 4 核，问题解决。

CPU 配额动态调整的核心指标：

  • CPU 使用率：超过 80% 就要考虑扩容或提高配额
  • CPU Throttle 率：超过 5% 说明 Limit 设得太紧
  • 负载波动曲线：根据业务高峰低谷动态调整 Request/Limit

2.2 内存：不可压缩，超卖就是找死

内存和 CPU 完全不同。它是不可压缩资源。你申请了 4GB，系统就真的给你留 4GB。如果 Pod 想用 5GB，而 Limit 是 4GB，那不好意思——OOM Kill。

我记得有一次线上事故，就是因为内存配额设得太紧。一个数据处理任务在高峰期内存暴涨，直接 OOM，Pod 重启了 3 次，数据丢了半天的量。从那以后，我定了一条铁律：内存的 Limit 至少要比 Request 高 20%-30%，给 GC 和突发留余量。

避坑指南：我曾经见过有人把内存 Request 和 Limit 设成一样，觉得这样「公平」。结果业务一波动，Pod 全挂了。内存超卖是集群稳定性的大敌，尤其是 Java、Python 这类有 GC 的语言。

内存动态调整的关键参数：

参数 说明 建议值
Request Pod 保证能拿到的内存 基线使用量 + 10% 余量
Limit Pod 能使用的上限 Request × 1.3 ~ 1.5
OOM 阈值 触发 OOM Kill 的临界点 Limit 的 95% 开始预警

2.3 GPU：稀缺资源，必须精细管控

GPU 是集群里最贵的资源，没有之一。一块 A100 好几万，你舍得让它空转吗？

GPU 的配额管理比 CPU/内存复杂得多。首先，它不支持超卖——你申请了 1 张卡，调度器就真的给你绑 1 张卡。其次，GPU 的显存是独立资源，和 GPU 核心是两回事。

我建议的做法是：

  • 按卡分配：每个 Pod 至少申请 1 张完整 GPU，避免碎片化
  • 显存监控：显存使用率超过 90% 就要告警
  • MIG 或 vGPU：如果卡多任务少，可以考虑 GPU 分区技术
实战经验：我在一个 AI 训练平台上，发现很多用户申请了 8 张 GPU，但实际只用 4 张。后来我们做了 GPU 使用率监控，发现平均利用率只有 40%。于是加了动态回收机制——如果 Pod 连续 10 分钟 GPU 利用率低于 20%，自动缩减配额。

2.4 存储：本地盘 vs 云盘，选型决定配额策略

存储这块，很多人容易忽略。其实存储的配额管理直接影响 Pod 的调度和性能。

先看本地盘：

  • 性能好，延迟低，但不持久——Pod 漂移后数据就没了
  • 适合临时数据、缓存、日志
  • 配额主要管磁盘空间和IOPS

再看云盘：

  • 持久化存储，Pod 挂了数据还在
  • 性能取决于云盘类型（SSD/高效云盘/普通云盘）
  • 配额要管容量、IOPS、吞吐量

我个人习惯把存储配额分成两层：

  1. Pod 级别：通过 PVC 的 Request 控制每个 Pod 能用的存储空间
  2. 命名空间级别：通过 ResourceQuota 限制整个命名空间的存储总量
注意：我曾经遇到一个案例，某个团队给每个 Pod 申请了 100GB 云盘，但实际只用 10GB。结果集群里 100 个 Pod 占了 10TB 存储，其他团队没空间了。后来我们加了存储配额动态回收——如果 Pod 连续 7 天存储使用率低于 30%，自动缩减 PVC 容量。

2.5 网络带宽：最容易忽视的瓶颈

网络带宽是配额管理里的「隐形杀手」。CPU 和内存配得再好，网络一堵，应用照样卡死。

Kubernetes 原生对网络带宽的支持比较弱，但我们可以通过 CNI 插件或 QoS 策略来实现：

  • Ingress/Egress 限速：通过 Cilium 或 Calico 的 NetworkPolicy 做带宽限制
  • Pod 级别带宽：使用 Kubernetes 的 kubernetes.io/ingress-bandwidth 和 kubernetes.io/egress-bandwidth 注解
  • 节点级别带宽：通过 TC (Traffic Control) 做节点出口限速
我的做法：我一般会在命名空间级别设一个总带宽配额，然后每个 Pod 再设一个带宽上限。比如，命名空间总出口带宽 1Gbps，每个 Pod 最多 100Mbps。这样既保证公平，又防止单个 Pod 把带宽吃光。

2.6 Pod 数量：配额管理的「最后一公里」

Pod 数量配额，很多人觉得简单——不就是限制一个命名空间能跑多少个 Pod 吗？

其实没那么简单。Pod 数量配额要和资源配额联动。比如，你限制了命名空间最多 100 个 Pod，但每个 Pod 申请 4 核 8GB，那这个命名空间就能吃掉 400 核 800GB 内存——集群扛得住吗？

我建议的 Pod 数量配额策略：

维度 说明 示例
Pod 总数 命名空间最多能跑多少个 Pod 100
单 Pod 资源上限 每个 Pod 能申请的最大资源 8 核 32GB
总资源上限 命名空间所有 Pod 的资源总和上限 200 核 1TB
核心原则：Pod 数量配额不是孤立存在的。它要和 CPU、内存、GPU、存储的配额一起算。我见过一个团队，Pod 数量配额设了 200，但 CPU 配额只给了 50 核——结果 Pod 全 Pending，因为调度器发现 CPU 不够。

2.7 资源类型全景图

说了这么多，我把这六种资源类型的关系画成一张图，方便你理解。

资源类型全景图 资源配额管理 CPU (可压缩) 内存 (不可压缩) GPU (稀缺资源) 存储 (本地/云盘) 网络带宽 Pod 数量 动态调整要点 可压缩：可超卖 不可压缩：留余量 稀缺资源：精细管控

这张图你看懂了吗？中心是资源配额管理，向外辐射六种资源类型。每种资源都有自己的特性——CPU 可压缩、内存不可压缩、GPU 稀缺、存储分本地和云盘、网络带宽容易堵、Pod 数量要和资源联动。

← 上一章 📖 返回目录 下一章 →