Pod CPU节流

Question

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

然后，我开始查看CPU限制指标，发现我所有的pod都被限制了。然后，我将其中一项服务的限制从250m增加到1000m，而在该吊舱中看到的节流减少了，但是我不明白为什么如果吊舱未达到其旧极限（250m），我应该设置更高的限制）。

所以我的问题是：如果我没有达到CPU限制，为什么我的Pod节流？如果豆荚没有充分利用容量，为什么我的响应时间会增加？

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

CPU使用率（在这里我们可以看到此Pod的CPU从未达到其250m的限制）：

CPU节流：

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

kubectl上衣

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

PS 2：我的节点都没有面临高使用率。实际上，它们都不在任何时候都使用超过50％的CPU。

提前致谢！

Answer 1

Kubernetes 使用（完全公平调度程序）CFS 配额对 pod 容器实施 CPU 限制。有关更多详细信息，请参阅https://kubernetes.io/blog/2018/07/24/feature-highlight-cpu-manager/ 中描述的“CPU Manager 如何工作” 。

CFS是Linux的一个特性，是2.6.23内核添加的，它基于两个参数：cpu.cfs_period_us和cpu.cfs_quota 为了形象化这两个参数，我想借用Daniele Polencic的下图博客（https://twitter.com/danielepolencic/status/1267745860256841731）：

如果您在 K8s 中配置 CPU 限制，它将设置周期和配额。如果在容器中运行的进程达到限制，它将被抢占并必须等待下一个时期。它被节流了。所以这就是你正在体验的效果。周期和配额算法不应被视为 CPU 限制，如果未达到，进程将不受限制。该行为是令人费解，也K8S问题存在此：https://github.com/kubernetes/kubernetes/issues/67577 中给出的建议https://github.com/kubernetes/kubernetes/issues/51135是不要为不应受到限制的 pod 设置 CPU 限制。

Answer 2

TLDR：消除 CPU 限制。（除非此警报metrics-server在这种情况下不起作用。）CPU 限制实际上是一种不好的做法，而不是最佳做法。

为什么会发生这种情况

我将重点讨论要做什么，但首先让我举一个简单的例子来说明为什么会发生这种情况：

1. 想象一个 CPU 限制为 100m 的 pod，相当于 1/10 vCPU。
2. Pod 在 10 分钟内不执行任何操作。
3. 然后它会不间断地使用CPU 200ms。突发期间的使用量相当于 2/10 vCPU，因此 pod 超出了其限制并将受到限制。
4. 另一方面，平均 CPU 使用率将非常低。

在这种情况下，您将受到限制，但突发非常小（200 毫秒），因此不会显示在任何图表中。

该怎么办

实际上，在大多数情况下，您不希望 CPU 限制，因为它们会阻止 pod 使用备用资源。有记录显示 Kubernetes 维护者表示您不应该使用 CPU 限制，而应该只设置请求。

更多信息

我写了一个完整的 wiki 页面来解释为什么尽管 CPU 使用率低但仍会发生 CPU 限制以及如何处理它。我还讨论了一些常见的边缘情况，例如如何处理metrics-server不遵循通常规则的情况。

Answer 3

如果您看到在为CPU 发行a时看到的文档Request，它实际上使用了--cpu-sharesDocker中的选项，该选项实际上在Linux上对cpu，cpuacct cgroup使用cpu.shares属性。因此，值50m大约是--cpu-shares=51基于的1024。 1024代表100％的股份，因此51将是4-5％的股份。首先，这很低。但是这里重要的因素是，这与您的系统上有多少个pod /容器以及这些cpu共享（它们是否使用默认值）有关。

因此，假设在您的节点上，您有另一个默认共享为1024的Pod /容器，而您有一个具有4-5共享的Pod /容器。然后，此容器将获得约0.5％的CPU，而另一个容器/容器将获得约99.5％的CPU（如果没有限制）。因此，这又取决于节点上有多少个吊舱/容器以及它们的份额。

另外，在Kubernetes文档中没有很好地记录文档，但是如果Limit在Pod上使用，则基本上是在Docker中使用两个标志：--cpu-period and --cpu--quota实际上在Linux上对cpu，cpuacct cgroup使用cpu.cfs_period_us和cpu.cfs_quota_us属性。这是因为cpu.shares没有提供限制，所以您会遇到容器占用大部分CPU的情况。

因此，就此限制而言，如果在同一节点上还有其他没有限制（或更高限制）但具有更高cpu.shares的容器，则您将永远无法达到它，因为它们最终将进行优化并选择空闲状态中央处理器。这可能是您所看到的，但再次取决于您的具体情况。

在此对以上所有内容进行更详细的说明。