Docker基础教程（253）Docker资源控制之限制CPU：别让容器变成“饿狼”！Docker CPU限制终极减肥训练营，附完整喂食手册-优快云博客

引言：一场由“饿狼”引发的血案

想象一下这个场景：你精心打造的微服务架构正在平稳运行。突然，监控警报凄厉作响——服务器负载飙升到100%，整个系统响应慢如蜗牛，用户投诉电话被打爆。你手忙脚乱地登录服务器，输入top命令，赫然发现一个名为app_v3_unsafe的Docker进程，正以199%的CPU占用率疯狂“啃食”着你的双核服务器！

元凶是谁？正是一个没有设置任何CPU资源限制的Docker容器。在Docker的默认设定下，每个容器都像是一个拥有“无限食欲”的客人，可以无节制地使用宿主机的CPU时间片。当一个容器因为bug、恶意攻击或设计缺陷而陷入死循环时，它就会化身为“饿狼”，挤占掉其他所有容器（甚至是宿主系统本身）的生存资源。

如何避免？答案就是：给容器“减肥”，为它戴上CPU的“紧箍咒”。今天，我们就一起走进Docker资源控制的“减肥训练营”，深度分析如何限制CPU，并附上从入门到精通的完整示例。

第一章：理解底层原理——CFS调度器，Docker的“营养分配师”

Docker对CPU的限制，并非凭空创造，而是基于Linux内核的完全公平调度器（Completely Fair Scheduler， CFS）实现的。你可以把CFS想象成一位公正无私的“营养分配师”。

它的目标是：在所有进程（包括容器化的进程）之间公平地分配CPU时间。
它的工具是：通过为进程控制组（cgroup）设置参数，来告诉内核这个组“应该吃多少”。

Docker引擎在启动容器时，会为它在cgroup的CPU子系统中创建一个专属目录，并通过修改该目录下的配置文件来实现资源限制。我们使用的所有Docker CPU参数，最终都会翻译成cgroup的配置。

理解这一点至关重要，它意味着Docker的资源控制是坚实、可靠的内核级功能，而非应用层面的“花拳绣腿”。

第二章：三大“减肥”秘籍，从入门到精通

Docker主要提供了三种方式来控制容器的CPU使用，对应三种不同的控制维度。

秘籍一：精准卡路里控制（--cpus）—— 最简单直观

这是最现代、最易用的方式。直接限定容器可以使用的CPU核心数上限。

命令示例：docker run -it --cpus=1.5 ubuntu:latest /bin/bash
含义：这个容器最多可以使用1.5个CPU核心的计算能力。无论宿主机有多少个核心，它都不能超过这个限额。
适用场景：绝大多数情况下的首选。你很清楚你的应用大概需要多少计算资源，直接设定一个上限，简单粗暴有效。

秘籍二：相对权重分配（--cpu-shares）—— 按需分配，弹性伸缩

这种方式不设置绝对上限，而是通过权重来分配CPU时间。默认值是1024。

命令示例：

# 容器A，权重512
docker run -d --name container_A --cpu-shares=512 my-app:latest
# 容器B，权重1024
docker run -d --name container_B --cpu-shares=1024 my-app:latest

含义：当所有容器都拼命想要使用CPU时，CFS调度器会按照权重比例分配时间片。在上面的例子中，如果只有A和B在竞争CPU，那么B获得的CPU时间将是A的两倍（1024/512 = 2）。但如果容器A在空闲，容器B仍然可以使用全部的CPU资源。
适用场景：适合一组重要性不同、但希望弹性利用空闲资源的容器。比如，核心业务应用权重设高，批处理任务权重设低。

秘籍三：核心绑定（--cpuset-cpus）—— 专属私教，避免干扰

这种方式将容器绑定到指定的CPU核心上执行。

命令示例：docker run -it --cpuset-cpus=0,3 ubuntu:latest /bin/bash
含义：这个容器里的进程只允许在编号为0和3的CPU核心上运行。
优势：

1. 避免上下文切换：可以减少进程在不同核心间切换带来的性能损耗。
2. 提高CPU缓存命中率：进程固定在一个核心上，数据更可能留在该核心的缓存中。
3. 隔离噪声：对性能要求极高的应用（如高频交易系统）可以独占核心，不受其他容器干扰。

适用场景：对性能极其敏感的应用，或者需要避免不同容器竞争同一缓存的应用。

第三章：实战演练——完整示例，手把手喂饭

光说不练假把式。下面我们通过一个制造CPU负载的脚本来亲眼见证限制的效果。

步骤1：准备一个“吃货”脚本

创建一个名为cpu_eater.py的文件，内容如下。这个脚本会疯狂创建线程，榨干CPU。

# cpu_eater.py
import math
import threading
import time

def waste_cpu():
    duration = 60  # 运行60秒
    end_time = time.time() + duration
    while time.time() < end_time:
        # 进行一些高强度的数学计算
        math.factorial(1000)

# 根据CPU核心数创建线程，确保能吃满
thread_count = 4  # 假设是4核机器，可以调整
threads = []
for i in range(thread_count):
    t = threading.Thread(target=waste_cpu)
    threads.append(t)
    t.start()

for t in threads:
    t.join()

print("CPU eating session finished!")

步骤2：构建Docker镜像

创建Dockerfile：

FROM python:3.9-slim
COPY cpu_eater.py .
CMD ["python", "cpu_eater.py"]

构建镜像：

docker build -t cpu-eater .

步骤3：进行对比实验

实验A：无限制的“饿狼”

docker run -d --name hungry-wolf cpu-eater

然后快速运行docker stats hungry-wolf观察。你会看到CPU占用率瞬间飙升到接近400%（对于4核机器），就像一匹脱缰的野马。

实验B：限制为1个CPU的“绅士”
先删除上一个容器：docker rm -f hungry-wolf

docker run -d --name polite-guest --cpus=1.0 cpu-eater

再次使用docker stats polite-guest观察。你会发现，无论脚本多么“努力”，CPU占用率都会稳稳地被限制在100%左右。这就是--cpus参数的魔力！

实验C：使用权重分配的“公平竞争”
打开两个终端。
终端1，启动一个高权重容器：

docker run -d --name big-app --cpu-shares=2048 cpu-eater

终端2，启动一个低权重容器：

docker run -d --name small-app --cpu-shares=512 cpu-eater

同时观察两者的状态：docker stats big-app small-app。你会看到，在CPU资源紧张时，big-app获得的CPU时间大约是small-app的4倍（2048/512=4）。但如果只有一个在运行，它依然可以吃满资源。

第四章：高级技巧与最佳实践

组合使用：你可以组合这些参数。例如，--cpus=2 --cpuset-cpus=0,1意味着容器最多使用2个CPU核心，并且只能运行在0号和1号核心上。
监控与调优：始终使用docker stats或更强大的监控工具（如Prometheus+Grafana）来观察容器的实际资源使用情况，并据此调整限制值。限制不是一成不变的。
避免设置过小：给容器分配的CPU过少，会导致应用性能瓶颈，反而适得其反。需要经过压测找到平衡点。

写在Compose里：在生产环境中，使用Docker Compose管理服务时，务必在docker-compose.yml中定义资源限制。

services:
  my-web-app:
    image: my-app:latest
    deploy:
      resources:
        limits:
          cpus: '1.5'
          memory: 512M
        reservations:
          cpus: '0.5'
          memory: 256M