Kubernetes CPU limits 正在拖慢你的应用
For the love of god stop using CPU limits in Kubernetes
我们实测发现，Kubernetes 中的 CPU limits 会让应用在节点空闲时也被每秒多次冻结，导致延迟飙升且成本增加。真正的保护来自 CPU requests，它通过 CFS 机制公平分配资源，而内存 limits 仍需保留以防 OOM。移除 CPU limits 后，尾部延迟在流量峰值下更稳定，CPU 密集型启动速度提升约两倍，同时还能释放闲置算力，显著降低硬件成本。别再让 limits 成为性能瓶颈，立即检查你的集群配置。
这就是容器被全天节流而仪表盘依然显示绿色的原因。
HN 评论区
42- conradludgate
虽然我同意 CPU 限制确实会让性能变差，但我觉得这篇文章的呈现方式说服力不够（而且充满了 LLM 特有的腔调，让我读不下去）。
它提到 CPU request 是一种保证，但这如何强制执行呢？如果我在一个 32 核的机器上运行 32 个 Pod，每个都请求了 1 个 CPU，有什么能阻止其中某个 Pod 占用不公平的份额吗？我猜我们只能依赖 Linux 调度器。如果我有 16 个请求 1 个 CPU 的 Pod 和 1 个请求 16 个 CPU 的 Pod，Linux 调度器会确保给那个 16 个 CPU 的 Pod 更多时间吗？还是说我们又回到了使用 cgroups？
- sjbzbeiks
这在纸面上听起来总是很好，这也是很常见的说法，但当你真正进入生产环境处理紧急升级时，一个非常普遍的问题是：很多软件依赖限制来自动配置线程池，甚至几个运行时环境（比如 Go 和 Java，文章中至少提到了 .net）也是如此。是的，你通常可以用一个标志位来设置，但人们必须知道这一点，去沟通它，去强制执行它。基本上，就是用临时的方案去替代限制原本为你自动完成的配置工作。
所以这完全假设你有一个所有团队都能完美沟通必要信息的设置……实际上发生的情况是，工作负载在边缘情况下会退化，因为线程池运行了 256 个线程而不是 4 个。
- dwedge
直接把提示词（prompt）给我吧
- inigyou
这篇文章大部分是 AI 写的
- aairey
这算哪门子“新闻”？
2018 年就已经这样了。
而且，完全没提调度器的开销。
维护开销才是最糟糕的。