容器使用共享资源限额#

cgroup 记录权重、上限与保护值，但多数配置并不提前占用物理资源。CPU 到达上限时被节流，进程仍可继续；内存达到硬上限时可能触发 OOM Kill。

requests 主要参与调度，limits 约束运行时使用。所有容器限额之和可以超过节点容量，空闲资源也能被其他工作负载复用，因此资源利用率高，但性能会受节点争用影响。

这些值是内核策略，可以在运行中修改。CPU 调整较直接；内存上调立即有效，下调则可能因为现有占用而失败或触发回收压力。

microVM 使用固定虚拟硬件#

microVM 启动时确定 vCPU 与内存，Guest Kernel 在该硬件视图内自行调度和 OOM。它看到的 /proc 与分配规格一致，资源边界更容易解释。

代价是弹性较弱。CPU 热插并非普遍能力，内存调整依赖 Balloon 或预声明的热插上限；超出边界通常需要以新规格重建实例。资源也更接近真实预留，密度通常低于可超卖容器。

CPU、内存和 GPU 不能共用一个结论#

GPU 尤其说明“内核资源”不是完整模型。设备显存和驱动调度不完全受普通 cgroup 控制，隔离保证需要单独验证，不能从 CPU/内存配置类推。

我的选择：先定义保证，再填写规格#

需要动态扩缩、GPU 生态和高密度超卖时，我会优先容器，并通过节点水位与服务等级管理争用。需要自洽资源视图、稳定预留和更强隔离时，选择 microVM，并接受重建与较低密度。

若业务只填写“2 核 4G”而没有说明这是上限、请求、保护还是预留，平台合同仍然不完整。资源 API 应明确超限行为、热调整能力和可观测指标，再映射到具体引擎。