首页/云/Kubernetes 速查/CPU 单位:核与毫核 m
调度与资源52 条

CPU 单位:核与毫核 m

CPU 以核为单位、以 m(千分之一核)为精度:500m = 0.5 核,100m 是常见的小请求粒度;调度按 requests.cpu 精确加和。

Kubernetes 速查云更新于 2026-10-13

CPU 单位是什么

CPU 以核为基本单位,以毫核为精度:一个核等于一千毫核,五百毫核就是半个核。写法上可以写整数核,也可以写带有毫核后缀的值。这个单位出现在请求值与上限值里,调度器会把所有容器的请求按毫核求和后与节点的可分配量比较,决定这个对象能不能放上去。

为什么用毫核而不是核

一个核对许多服务来说太大,用小数值又会出现浮点表达的问题,毫核提供了整数化的细粒度表达。它带来的直接好处是资源可以精确切分,一台机器上可以按需放进大量小规格服务。代价是必须记住换算关系:写错一个数量级,可能出现「节点看着空闲却调度不上去」的现象。

基本信息

适用环境任何 Kubernetes 发行版,用于容器的资源请求与上限字段
换算关系一个核等于一千毫核
常见取值小请求常按毫核写,大规格可按整数核写
书写形式整数、毫核后缀、小数均可,团队内保持统一
调度依据请求值按毫核求和后与节点可分配量比较
查看方式节点描述里的已分配资源段按核显示

典型使用场景

  • 小规格服务声明:轻量接口服务按几十到几百毫核申请资源
  • 批量服务规划:按毫核精确分配,提高单节点承载数量
  • 容量核算:把请求值汇总后与节点可分配量对比,判断能否再放实例
  • 排查调度失败:确认是请求值总量超出,还是被其他约束挡住
  • 评估超卖:对比请求值之和与实际用量,判断节点是否已经过度承诺
  • 成本优化:根据实际用量与请求值的差距调整申请规模

写法对照

写法对照
resources:
  requests:
    cpu: 250m        # 零点二五核
  limits:
    cpu: "2"         # 两个核,字符串或整数写法均可
# 换算:1000m = 1 核;100m 是十分之一个核,是常见的小请求粒度

节点视角核对

节点视角核对
kubectl describe node node-1 | grep -A8 'Allocated resources'   # 已分配请求与占比
kubectl describe node node-1 | grep -A6 Capacity                 # 总容量
kubectl describe node node-1 | grep -A6 Allocatable              # 可分配量
kubectl top node node-1                                           # 实际用量对照

三个量要分清

概念含义用途
总容量机器的物理核数参考上限,不作为调度依据
可分配量扣除系统预留后可供业务使用的部分调度的实际上限
已分配量当前所有请求值之和与新对象请求比较判断能否放下
实际用量真实消耗的核数评估请求值是否偏高或偏低
节点描述里的已分配资源按核显示,八百毫核会显示为零点八,读的时候注意单位换算。
不写上限时容器可以突发占满空闲节点,多租户或混部场景应显式声明上限,避免互相干扰。

易错点

  • 把毫核当成核来写:请求值被放大千倍,节点看起来空闲却始终调度不上去
  • 只看总容量不看可分配量:业务实际可用量小于机器规格,容量评估过于乐观
  • 请求值按峰值填写:装箱保守、节点利用率低,扩容成本明显上升
  • 不声明上限:空闲节点上单个容器可突发占用大量算力,影响同节点其他服务

数据来源与参考

  • Kubernetes 官方文档 · 管理容器的计算资源
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌