平台工程 · 分析 我们在有无CPU限制的情况下测试了同一个应用程序。相同的代码，相同的CPU请求，相同的负载。唯一的区别是限制。以下是我们测量的数据——以及如何在您自己的集群中检查它。 TL;DR：去掉CPU限制。即使节点有空闲CPU，它们会每秒冻结您的应用程序多次。保持CPU请求。请求才是真正的保护。它们保证每个应用程序获得其份额。保持内存限制。内存是不同的。内存限制仍然保护节点。更快：在流量高峰期间，尾延迟保持稳定，而不是崩溃，CPU绑定的启动工作完成的速度大约快2倍（第5节，第10节）。更少的硬件：大多数集群在高峰期保留的CPU远远超过它们实际使用的CPU。去掉限制后，正确调整请求使得一部分节点可以被释放（第10节）。更便宜：一个经过验证的成本模型将这个成本估计为每个集群每年数万美元（第10节）——插入您自己的价格以获得实际数据。在此分析中： 1. 请求与限制 2. 节流的工作原理 3. CFS公平共享 4. 最坏情况 5. 我们测量的内容 6. 吵闹的邻居 7. 何时会崩溃 8. .NET的一步 9. 计划 10. 结果 11. 问答 12. 术语表 深入分析。本页是论据，里面的每个主张都有更长的文档支持，在您阅读时在线链接并收集在此： docs/01-theory.md cgroup机制：cpu.max与cpu.weight，多线程配额消耗，以及一个配置确实有助于CPU限制的地方。 docs/02-dotnet.md CPU限制对.NET运行时的影响：ProcessorCount，线程池饥饿，GC堆计数，以及CPU限制如何导致内存杀死。 docs/03-postgres.md Postgres的特定信息：为什么在自我调整大小时忽略您的配额，以及这个PoC测量的效果与仅仅推断的效果。 docs/04-objections.md 每个反对论点的回应——吵闹的邻居、HPA/KEDA、QoS等级、多租户以及何时限制是正确的。 docs/05-cost.md 完整的成本模型、其假设和内存底线，防止释放的核心变成释放的资金。 docs/06-rollout.md 分阶段推出：六个步骤，哪些是门，单行回滚。 results/ 基准运行的原始输出，以及下面数字来源的每个场景报告。 1. 两种设置，两种截然不同的工作 CPU请求 CPU限制 什么是 保证的CPU份额 一个硬上限，墙 保护其他应用程序？ 是的。CPU由请求大小共享。 不。它只阻止其自身的应用程序。 节点上的空闲CPU 应用程序可以免费借用 浪费。限制阻止它。 同一个应用程序两次。唯一的区别是对节点空闲CPU的访问。请求（实线）在两行中是相同的——借用空闲CPU不会从任何人那里减少任何东西。 更深层次：这两个是不同的cgroup文件，而不是一个旋钮的两个设置。 docs/01-theory.md 介绍cpu.max（限制）和cpu.weight（请求）以及每一个实际控制的内容。 2. 限制如何真正阻止您的应用程序 内核（操作系统的核心部分）在100毫秒的窗口中执行限制。500m的限制（500毫核，半个核心）意味着：每个窗口50毫秒的CPU时间。当预算耗尽时，内核会冻结整个应用程序，直到下一个窗口。这就是节流。一个典型的.NET服务运行许多线程：HTTP处理程序、后台消费者和GC（垃圾收集器）。所有线程共享一个预算。我们的测试节点有4个核心，因此最多只能同时运行4个线程。8个忙碌的线程在大约12.5毫秒的现实时间内用完50毫秒的预算：冻结最多每秒重复10次。下一张图表显示出为什么您的仪表板从未看到它们。每一个橙色时刻应用程序达到了其限制，内核冻结了它。1分钟的平均值从未接近限制，因此每个图表看起来都是健康的。这就是为什么一个容器可以整天受到节流，而其仪表板保持绿色。如果您只查看平均CPU，您无法看到这一点——而是检查container_cpu_cfs_throttled_periods_total。 我们证明了这一点。我们向具有500m限制的应用程序发送了平均只需320m的负载。平均值从未触及限制。应用程序仍然暂停： 同一个应用程序，相同负载（8个并行任务，5毫秒，每秒8个请求）。限制使得慢请求变得慢了2.4倍，而平均CPU仍远低于限制。 更深层次：为什么并行性使得情况比看起来更糟——16个线程在不到2毫秒的实际时间内耗尽300m的配额——以及原因是出现停滞而不是减速，这就是摧毁您的尾延迟的原因，而平均看起来很好。 3. 没有限制，谁分享CPU？ 认识CFS Linux有内置的裁判：CFS，完全公平调度器。每个pod都有一个权重。Kubernetes根据pod的CPU请求设置权重。规则很简单：当节点完全繁忙时，pod根据其权重共享CPU。当一个pod处于空闲状态时，它停止使用其份额。其他pod可以使用该份额。空闲的pod在再次工作时会立即恢复其份额。