首先要指出的是，CPU 资源通常比内存更灵活。当程序需要工作时，它会执行指令，cpu 会尽快处理这些指令，然后程序和 cpu 都会返回空闲状态，除非有更多工作要做。该程序可能会在一秒钟内使用一个 cpu 内核的百分之一，下一秒使用一个内核的 100%，然后回到空闲状态。
这是一个 cpu 利用率图表，描述了处理 Web 请求的应用程序的 cpu 使用情况。即使将使用情况聚合到分钟级别，我们也看到该程序在 1% 到 24% 的 cpu 利用率范围内运行。
程序的 CPU 使用率是高度量化的，并且在每秒“达到 100%”的许多非常短的突发中消耗。这意味着限制使用的策略可能与内存使用不同。服务器应用程序可能会在启动时静态分配内存，构建内存缓存，并以与处理工作负载不直接相关的其他方式消耗内存。
Docker 通过容器的 cgroup 向您公开两个主要的 Linux cpu 使用控制：
CPU份额
CPU配额
该cpu-shares选项允许您指定当争用 cpu 时容器将接收的 cpu 的相对份额。
当没有对 cpu 的争用时，无论“限制”是多少，容器都可以使用它想要的数量。
当存在争用时，配置为 2048 个 cpu 份额的容器将获得两倍于请求 1024 个 cpu 份额的容器的 cpu 时间。
资源cpu-shares约束功能从 Docker 的早期版本开始就可用。
让我们来看一个例子。我在一台有 4 个内核的机器上使用 Docker。
首先在一个终端中启动docker stats，仅显示容器名称、cpu 使用情况和内存使用情况：
docker stats --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.MemPerc}}"
在第二个终端中，启动第 6 章中使用的 Docker in Action“stresser”图像：
docker container run --name stresser-1024 \
--cpu-shares 1024 \
dockerinaction/ch6_stresser
Dockerstats命令显示stresser-1024容器使用了 398% 的 CPU——所有四个核心：
NAME CPU % MEM USAGE / LIMIT MEM %
stresser-1024 398.29% 1.102MiB / 1.945GiB 0.06%
现在让我们看看当运行第二个具有两倍 CPU 份额的容器时会发生什么：
docker container run -d --name stresser-2048 \ --cpu-shares 2048 \ dockerinaction/ch6_stresser
并重启stresser-1024容器：
docker container start stresser-1024
现在有两个进程都想占用 100% 的 CPU 资源，Linux 将这些资源按比例分配给它们：
NAME CPU % MEM USAGE / LIMIT MEM %
stresser-2048 263.26% 1.078MiB / 1.945GiB 0.05%
stresser-1024 131.42% 1.035MiB / 1.945GiB 0.05%
事实上，stresser-2048获得的 cpu 是 (131%) 的两倍 (263% stresser-1024)。
请注意，虽然我们将 cpu 份额指定为所需处理器的隐含数量乘以 1024，但这并未将进程限制为一个或两个内核。机器上的四个核心都用上了。
如果要强制执行绝对限制，则需要指定 cpu 配额。
Docker 允许您通过 Docker 1.13 中引入的选项轻松配置绝对cpu 配额--cpus。此 cpu 配额指定容器在被限制之前有权使用的固定 cpu 份额。配额在容器的 cgroup 中定义，并由 Linux 的Completely Fair Scheduler强制执行。
让我们通过启动每个配额为 1 和 2 cpu 的 stresser 容器来查看它的实际效果：
docker container run -d --name stresser-1-cpus \
--cpus 1 \
dockerinaction/ch6_stresser
docker container run -d --name stresser-2-cpus \
--cpus 2 \
dockerinaction/ch6_stresser
现在统计数据显示了一个截然不同的故事：
NAME CPU % MEM USAGE / LIMIT MEM %
stresser-1-cpus 100.17% 1.098MiB / 1.945GiB 0.06%
stresser-2-cpus 201.14% 1.07MiB / 1.945GiB 0.05%
压力程序仅限于我们指定的 CPU 数量。当一个程序用完配额时，Linux 内核会延迟运行该程序，直到配额得到补充。配额每 100 毫秒分配和执行一次。
cpu 份额和配额资源约束机制都是有用的。
CPU 份额可以帮助您在共享主机的容器化进程之间建立相对优先级。此外，由于 CPU 份额在绝对 CPU 约束选项之前可用，因此大多数容器编排器都知道如何使用以“millicores”表示的 cpu 份额。这些编排器将接受以毫核表示的请求或限制，在假设每个核值 1024 毫核的情况下寻找具有足够资源的容器主机，然后相应地为容器配置 cpu-shares。这近似于为许多用例指定一定数量的 cpu 的能力。
CPU 份额崩溃的地方之一是当您不希望容器在主机上没有争用时能够突破其份额。有许多有效的用例，例如：
防止隔离服务的负载测试在测试环境中使用整台机器，而该服务将只有部分机器用于生产
建立硬性预算，出于调度、安全、计费或会计原因限制服务可用的资源
还有其他几个 cpu 约束和应用它们的方法。查看Docker in Action 的第 6 章，第 2ed了解更多信息或点击回复并提出问题。
来源：
https://www.toutiao.com/article/7208003506416910908/?log_from=170a81d69475f_1678323541417