Docker通过--cpus、--cpu-shares、--cpuset-cpus等参数限制容器CPU资源，底层基于cgroup v1/v2机制；推荐优先使用--cpus实现直观的硬上限控制，并结合--cpuset-cpus提升NUMA亲和性与隔离性。
在 Linux 中，Docker 默认使用 Cgroups（Control Groups）来管理容器资源，包括 CPU。你无需手动操作底层 Cgroups，而是通过 Docker 命令参数即可完成 CPU 限制，但理解其背后的 Cgroups 机制有助于排查问题和定制高级策略。
CPU 限制的核心参数（Docker 命令级）
Docker 提供了多个 CPU 相关选项，对应不同维度的控制逻辑：
-
--cpus=2.5：限制容器最多使用 2.5 个逻辑 CPU 核心（如双核四线程机器上可跑满 2.5 个 vCPU）。这是最直观、推荐用于大多数场景的方式，底层映射到
cpu.max（cgroup v2）或cpu.cfs_quota_us+cpu.cfs_period_us（cgroup v1）。 - --cpu-shares=512：设置 CPU 权重（默认为 1024），仅在多个容器争抢 CPU 时生效，不设硬上限。例如两个容器分别设 512 和 1024，则 CPU 时间按 1:2 分配。
- --cpuset-cpus="0-1"：将容器绑定到特定 CPU 核心（如仅允许使用核心 0 和 1），适用于 NUMA 或隔离性要求高的场景。
-
--cpu-quota=50000 --cpu-period=100000：等价于
--cpus=0.5。表示每 100ms（period）最多运行 50ms（quota），即 50% CPU 时间。注意：Docker 1.13+ 推荐优先用--cpus，更易读且自动处理 period/quota 比例。
验证容器是否真的受限
启动容器后，可通过以下方式确认 Cgroups 配置已生效：
- 查容器 cgroup 路径：
docker inspect | grep -i cgroup，找到HostConfig.CgroupParent或Id，再结合/sys/fs/cgroup/cpu/（v1）或/sys/fs/cgroup/（v2）查看对应目录下的cpu.max或cpu.cfs_quota_us值。 - 进入容器执行
cat /sys/fs/cgroup/cpu.max（cgroup v2）或cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us（v1），确认数值与预期一致（如50000 100000表示 0.5 核）。 - 在宿主机用
top -p $(pgrep -f "docker-containerd.*")或htop观察进程 CPU 使用率是否被压在设定上限内。
注意事项与常见误区
实际使用中容易忽略的关键点：
- Docker 默认启用 cgroup v2（较新内核 + systemd 环境），但部分旧系统仍为 v1；
docker info | grep "Cgroup Version"可确认版本，不同版本下文件路径和参数名略有差异。 -
--cpus是软上限，容器在空闲时仍可突发使用全部 CPU，只有在争抢时才被节流；若需严格隔离，需配合--cpuset-cpus使用。 - 当宿主机启用了 CPU 频率调节器（如
ondemand），即使容器 CPU 被限制，单核频率可能仍会拉升，造成功耗/温度误判——必要时可统一设为performance模式。 - Swarm 或 Kubernetes 等编排平台会覆盖部分 Docker 原生命令参数，此时应通过平台自身的资源定义（如 Pod 的
resources.limits.cpu）来设置。
一个实用例子：限制 Web 服务容器为 1.2 核并绑定到前两核
运行命令如下：
docker run -d --name nginx-limited --cpus=1.2 --cpuset-cpus="0-1" -p 8080:80 nginx
该容器最多使用 1.2 个逻辑 CPU 时间，并且只会在物理核心 0 或 1 上调度，避免跨 NUMA 节点访问内存，兼顾性能与可控性。
