2. 资源抽象模型：CPU、内存、GPU、磁盘、网络等资源的量化表示，资源预留与超卖策略
各位同学，咱们今天聊点实在的。资源抽象模型，说白了就是怎么把物理机器上的那些硬件——CPU、内存、GPU、磁盘、网络——变成调度器能看懂、能分配的数字。我刚开始接触集群调度时，觉得这玩意儿不就是“有多少分多少”嘛，结果第一次上线就踩了坑。嗯，咱们一步步来拆解。
2.1 资源量化：给硬件“称重”
调度器不认识“这颗CPU是3.0GHz的”，它只认数字。所以我们需要一套标准化的计量单位。
CPU 的量化
我个人习惯用“核”或“毫核”（mCPU）来量化。1 核 = 1000 mCPU。比如一个任务需要 0.5 核，就写 500m。为什么用毫核？因为粒度更细，调度更灵活。我在项目中遇到过，如果只用整数核，很多小任务会浪费大量碎片资源。
可分配 CPU = 总核数 × (1 - 系统预留比例) - 管理组件开销
内存的量化
内存就简单多了，直接用字节（Byte），但实际中我们常用 MiB 或 GiB。注意，这里有个坑：操作系统和调度器对“GB”的定义可能不同。操作系统用二进制（1 GiB = 1024 MiB），有些调度器用十进制（1 GB = 1000 MB）。我曾经因为这个差异，导致一个任务明明申请了 4GB，实际只拿到 3.7GiB，直接 OOM 了。
GPU 的量化
GPU 比较特殊。它不像 CPU 可以随便切分。我建议按“物理卡”或“显存切片”来量化。比如一张 NVIDIA A100 有 80GB 显存，你可以把它切成 4 个 20GB 的切片，每个切片算 0.25 卡。但注意，切片后性能会下降，因为显存带宽是共享的。
| 资源类型 | 常用单位 | 粒度 | 注意事项 |
|---|---|---|---|
| CPU | 核 / mCPU | 1m | 注意超线程的影响 |
| 内存 | GiB / MiB | 1MiB | 统一使用二进制单位 |
| GPU | 卡 / 显存切片 | 0.25卡 | 切片后性能下降 |
| 磁盘 | GiB / IOPS | 1GiB | 区分容量和性能 |
| 网络 | Mbps / 带宽 | 1Mbps | 注意多租户隔离 |
2.2 资源预留：给系统留条“后路”
你想想看，如果调度器把机器上所有资源都分配出去了，那操作系统自己用什么？系统进程、内核、监控代理都需要资源。所以必须预留一部分。
我一般会预留总资源的 5%-10% 给系统。具体多少取决于你的集群规模。小集群（10台以内）我建议留 10%，大集群（100台以上）可以降到 5%。为什么？因为大集群的管理组件（比如调度器本身）会分摊到更多机器上。
2.3 超卖策略：用“杠杆”撬动更多任务
超卖，说白了就是“明明只有 10 核，我敢卖 15 核”。为什么敢？因为大多数任务不会同时跑满。比如你的 Web 服务，白天忙晚上闲，如果按峰值分配，资源浪费太严重。
但超卖是把双刃剑。我见过一个案例：某团队把 CPU 超卖到 200%，结果双十一流量一来，所有任务都在抢 CPU，延迟飙升，最后雪崩了。
超卖的核心原则
- CPU 可以超卖，内存不建议超卖。 为什么？CPU 超卖只是变慢，内存超卖会触发 OOM Killer，直接杀进程。
- 设置超卖比例上限。 我个人习惯 CPU 不超过 150%，内存不超过 100%（即不超卖）。
- 区分“请求”和“限制”。 请求（request）是保证值，限制（limit）是上限值。超卖只在限制 > 请求时发生。
超卖比 = 所有容器限制值之和 / 节点可分配资源
安全阈值：CPU ≤ 1.5，内存 ≤ 1.0
2.4 知识体系总览
下面这张图是我自己画的，把资源抽象模型的核心逻辑串起来了。你看一眼就能明白整个流程。
2.5 实战中的避坑指南
最后，分享几个我踩过的坑，希望能帮你省点时间。
- 不要相信“平均负载”。 我曾经根据 CPU 平均负载来设置超卖比例，结果高峰期直接被打脸。平均负载会掩盖瞬时尖峰。建议看 P99 或 P95 分位值。
- 磁盘 IOPS 比容量更贵。 很多同学只关心磁盘大小，忽略了 IOPS。我遇到过数据库因为 IOPS 打满导致查询超时，但磁盘空间还剩 80%。
- 网络带宽要预留 20% 的余量。 不管你的业务模型是什么，网络总有突发流量。我曾经因为带宽跑满导致心跳超时，集群脑裂了。
好了，资源抽象模型这部分就聊到这儿。说白了，就是给硬件定个价，然后决定怎么卖、卖多少。下一节咱们聊聊调度器的核心算法，看看它到底是怎么做决策的。