资源隔离是容器技术最核心的价值之一，但很多团队在把容器推向生产环境时，往往只关注了镜像构建和编排调度，忽略了资源配额这块。结果就是某个容器里的应用出现内存泄漏，直接把宿主机的内存耗尽，内核OOM Killer开始随机杀进程，连带其他正常业务一起遭殃。Docker的资源配额本质上是借用了Linux内核的cgroup机制，理解了这套机制，不管是做资源管控还是做后续的按量计费，都会清晰很多。
一、Docker资源配额的底层原理：cgroup机制
Docker对容器资源的限制，最终都落地到Linux内核的Control Groups（cgroup）上。cgroup可以理解为一棵进程资源账本树，Docker在启动每个容器时，会在/sys/fs/cgroup目录下为容器创建一个独立的子组，把容器内所有进程都归到这个组里，然后通过写该组下的控制文件来限制资源。
具体来说，CPU限制对应cpu.cfs_quota_us和cpu.cfs_period_us两个文件，两者配合决定容器在每个调度周期内能使用的CPU时间片总量；内存限制对应memory.limit_in_bytes，当容器申请的内存超过这个值时，内核会触发OOM或者让申请失败；块设备IO限制则通过blkio子系统控制读写带宽和IOPS。Docker做的事情，只是把这些内核接口封装成了易用的命令行参数。
了解这一点很有必要，因为当你在宿主机上排查容器资源问题时，可以直接进入对应的cgroup目录查看实时数据。比如memory.usage_in_bytes记录了容器当前实际内存占用，cpuacct.usage记录了CPU累计使用时间，这些数据既是排查依据，也是后面做计费的数据来源。
二、CPU与内存配额的具体配置方法
先看CPU限制。Docker提供了几种不同粒度的CPU控制参数，各有适用场景：
# 限制容器最多使用1.5个CPU核心 docker run -d --cpus=1.5 nginx:alpine # 指定容器只能运行在CPU 0和CPU 1上 docker run -d --cpuset-cpus=0,1 nginx:alpine # 设置CPU权重（相对值，默认1024，仅在CPU争抢时生效） docker run -d --cpu-shares=512 nginx:alpine
这三个参数的区别需要分清楚：--cpus是硬上限，绝对不能超；--cpuset-cpus是绑核，把容器钉死在指定核心上，适合对缓存亲和性敏感的应用；--cpu-shares是软限制，只在宿主机CPU紧张时才起作用，平时空闲的容器可以借用额外算力。生产环境推荐用--cpus设置绝对上限，同时用--cpu-shares区分业务优先级。
再看内存限制，这块的坑相对多一些：
# 限制容器内存为512M，超过则触发OOM docker run -d --memory=512m nginx:alpine # 限制内存加swap总量为1G docker run -d --memory=512m --memory-swap=1g nginx:alpine
这里有个关键细节：--memory-swap的含义是内存加交换分区的总量。如果只设置--memory而不设置--memory-swap，容器默认可以使用两倍于内存限制的swap。对于Java应用，还有一个经典问题：JVM默认按照宿主机内存来推算堆大小，而容器内存被限制得比宿主机小得多，结果JVM堆还没扩到顶，容器就被OOM杀掉了。解决办法是升级到JDK 8u191以上版本并开启容器感知，或者直接用-XX:MaxRAMPercentage显式指定堆内存占容器内存的百分比。
如果用docker compose管理服务，等价的写法如下：
services:
web:
image: nginx:alpine
deploy:
resources:
limits:
cpus: '1.5'
memory: 512M
reservations:
cpus: '0.5'
memory: 256Mlimits是硬上限，reservations是软性的预留保障，两者配合可以在共享集群里实现更精细的资源分配。
三、从资源用量到计费模型的落地
有了资源配额，下一步就是成本核算。容器计费的核心思路是把每个容器实际消耗的资源采集下来，按定价换算成费用。数据采集有几个途径：最轻量的方式是定期读取cgroup文件，把cpuacct.usage的差值除以采集间隔得到CPU使用率，把memory.usage_in_bytes做时间加权平均得到平均内存占用；更通用的是通过Docker提供的stats接口批量拉取：
# 查看所有运行中容器的实时资源占用
docker stats --no-stream --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"如果需要长期存储和按团队分摊成本，建议把数据接入Prometheus加cAdvisor的监控体系，cAdvisor会按容器维度持续上报CPU、内存、网络、磁盘指标，配合Grafana做聚合报表。计费换算上，常见的模型是按资源单位计价，比如CPU每小时0.1元每核、内存每小时0.05元每GB，用采集到的实际用量乘以单价再乘以时长，就能得到每个容器、每个业务组的账单。
还有一点值得注意：计费基于的是实际用量还是申请量，两种口径差异很大。按实际用量计费对使用者友好，但平台方可能承担超卖风险；按配额申请量计费账单稳定，但容易鼓励用户超额申请造成资源浪费。实践中比较常见的折中方案是保底加弹性，即按预留资源收保底费用，超出部分按实际峰值用量阶梯计价，这和公有云的计费逻辑是相通的。无论选哪种口径，前提都是资源配额必须先设置清楚，否则用量数据本身就没有可信的边界。
Docker资源配额Docker计费容器内存限制修改时间：2026-09-09 12:38:50