Kubernetes Pod CPU节流

在Kubernetes中使用CPU请求/限制时，我遇到了一个奇怪的问题。在设置任何CPU请求/限制之前，我的所有服务都表现得非常好。我最近开始设置一些资源配额，以避免未来资源匮乏。这些值是根据这些服务的实际使用情况设置的，但令我惊讶的是，在添加这些值之后，一些服务开始大幅增加其响应时间。我的第一个猜测是，我可能设置了错误的请求/限制，但查看这些指标发现，事实上，这个问题所面临的服务中没有一个接近这些值。事实上，其中一些更接近于要求而不是限制

然后我开始研究CPU节流指标，发现我所有的吊舱都被节流了。然后，我将其中一项服务的限制提高到1000米（从250米）并且我看到该吊舱中的节流更少，但我不明白如果吊舱没有达到原来的限制（250米），为什么我要设置更高的限制

所以我的问题是：如果我没有达到CPU限制，为什么我的吊舱会节流？如果吊舱未满负荷运行，为什么我的响应时间会增加？

这里有一些我的指标的屏幕截图（CPU请求：50m，CPU限制：250m）：

CPU使用率（在这里我们可以看到这个吊舱的CPU从未达到其250m的极限）：

CPU节流：

将该吊舱的限制设置为1000米后，我们可以观察到更少的节流

kubectl top

附言：在设置这些请求/限制之前，根本没有节流（如预期的那样）

第2点：我的节点没有一个面临高使用率。事实上，它们中没有一个在任何时候使用超过50%的CPU

提前谢谢

如果您在为cpu发出

请求时看到，它实际上使用Docker中的选项，该选项实际上使用Linux上的cpu.shares属性。因此，
50m
的值约为
--cpu共享=51
，基于最大值为
1024
<代码>1024

代表100%的股份，因此

51

将占股份的4-5%。首先，这个数字很低。但这里重要的因素是，这与您的系统上有多少吊舱/容器以及这些吊舱/容器的cpu共享有关（它们是否使用默认值）

假设在您的节点上，您有另一个包含1024个共享的pod/容器，这是默认值，您有一个包含4-5个共享的pod/容器。然后这个容器将获得大约0.5%的CPU，而另一个pod/容器将 获得大约99.5%的CPU（如果没有限制的话）。因此，这同样取决于节点上有多少吊舱/容器以及它们的共享

另外，在中没有很好的记录，但是如果在pod上使用

Limit

，它基本上在Docker中使用两个标志：它实际上使用Linux上的cpu.cfs_period_us和cpu.cfs_quota_us属性。这是因为cpu.shares没有提供限制，所以容器会占用大部分cpu

因此，就这个限制而言，如果在同一个节点上有其他容器没有限制（或更高的限制），但是有更高的cpu.shares，那么就永远不会达到这个限制，因为它们最终会优化和选择空闲的cpu。这可能是你所看到的，但同样取决于你的具体情况

对以上所有内容的详细解释。

Kubernetes使用（完全公平的调度程序）CFS配额来强制pod容器上的CPU限制。有关更多详细信息，请参阅中描述的“CPU管理器如何工作”

CFS是一个Linux特性，与2.6.23内核一起添加，它基于两个参数：cpu.CFS_period_us和cpu.CFS_quota 为了可视化这两个参数，我想借用Daniele Polencic优秀博客（）中的以下图片：

如果您在K8s中配置CPU限制，它将设置时段和配额。如果容器中运行的进程达到限制，它将被抢占，并且必须等待下一个周期。它被节流。 这就是你正在经历的效果。周期和配额算法不应被视为CPU限制，如果未达到该限制，则进程将不受限制。 该行为令人困惑，并且存在K8s问题：

---

中给出的建议是不要为不应节流的POD设置CPU限制。

首先，感谢您的回答。我可能得不到什么。上面你说50米是一个很低的值。虽然我同意这一点，但上面的指标表明，50米是该pod的实际使用量，那么为什么我会要求它有更多的cpu时间呢？我将检查是否有一些容器未配置请求/限制。你能澄清一下吗？这是

50m

，因为这是你要求的最小值（CPU的4-5%），但也可能有其他吊舱达到

1000m

或

1024m

，即使你定义了

限制，也会使
50m
达到最大值。我喜欢你的解释，但我在一个五节点集群上运行106个吊舱。每个节点有4个核心，因此总容量为20000m。这意味着，如果容器默认请求1024m，我只能调度20个吊舱。此外，kubernetes仪表板显示只有25%-50%的CPU被请求。在这种情况下不应该是100%？我检查了一下，我有一些没有限制的豆荚。我想我可以测试在名称空间上设置一个资源配额来限制所有的pod是的。如果它们没有限制，它们可能会在最小cpu共享方面溢出。