CPU 限制在 Kubernetes 中有何用途？码头工人？

Question

我深入研究 Kubernetes 资源限制，很难理解 CPU 的用途limits。我知道 Kubernetes 通过requests了并且limits下到（在我的例子中）Docker 运行时。

示例：我有 1 个带有 1 个 CPU 的节点和 2 个带有 CPUrequests: 500m和limits: 800m. 在 Docker 中，这会导致 ( 500m -> 0.5 * 1024 = 512)--cpu-shares=512和 ( 800m -> 800 * 100) --cpu-quota=80000。Pod 由 Kube 调度程序分配，因为requests总和不超过节点容量的 100%；limits就节点而言是过度使用的。

上面允许每个容器每 100 毫秒周期获得 80 毫秒 CPU 时间（默认）。一旦 CPU 使用率达到 100%，CPU 时间就会根据容器的权重在容器之间共享，以 CPU 份额表示。根据 1024 的基值，每个集装箱占 50%，每个集装箱占 512 个份额。在这一点上 - 根据我的理解 - 它们limits不再具有相关性，因为没有一个容器可以再获得 80 毫秒的时间。他们都会得到 50 毫秒。因此，无论我定义多少limits，当使用率达到临界 100% 时，无论如何都会对其进行分区requests。

这让我想知道：为什么我应该limits首先定义 CPU，过度使用有什么区别吗？requests另一方面，“当一切都在使用时我能得到多少份额”是完全可以理解的。

Answer 1

根据Kubernetes 演练将 CPU 资源分配给容器和 Pod 的 CPU 请求和限制的动机部分：

\n\n

\n

通过使 CPU 限制大于 CPU 请求，您可以完成两件事：

\n\n

\n
• Pod 可能会发生突发活动，从而利用恰好可用的 CPU 资源。
\n
• Pod 在突发期间可以使用的 CPU 资源量被限制在某个合理的数量。
\n

\n

\n\n

我想这可能会让我们想知道为什么我们关心将突发限制为“某个合理的数量”，因为它可以突发的事实似乎表明当时没有其他进程争夺 CPU。但我发现自己对这种推理不满意......

\n\n

因此，首先我检查了您提到的 docker 标志的命令行帮助：

\n\n

    --cpu-quota int                  Limit CPU CFS (Completely Fair Scheduler) quota\n-c, --cpu-shares int                 CPU shares (relative weight)\n

\n\n

引用 Linux Completely Fair Scheduler 意味着为了了解 CPU 限制/配额的值，我们需要了解底层进程调度算法的工作原理。有道理，对吧？我的直觉是，它并不像根据 CPU 份额/​​请求对 CPU 执行进行时间切片并按照先到先得的原则分配某个固定时间片结束时剩余的内容那么简单。

\n\n

我发现这篇旧的 Linux Journal 文章片段似乎是 CFS 工作原理的合法描述：

\n\n

\n

CFS 尝试跟踪系统中每个进程可用的 CPU 的公平份额。因此，CFS 以实际 CPU 时钟速度的一小部分运行公平时钟。公平时钟的增加率是通过将挂起时间（以纳秒为单位）除以等待的进程总数来计算的。结果值是每个进程有权使用的\n CPU 时间量。

\n\n

当进程等待 CPU 时，调度程序会跟踪它在理想处理器上使用的时间量。该等待时间由每个任务的 wait_runtime 变量表示，用于对进程进行排序以进行调度，并确定进程在被抢占之前允许执行的时间量。等待时间最长的进程（即最需要 CPU 的进程）由调度程序挑选并分配给 CPU。当此进程运行时，其等待时间会减少，而其他等待任务的时间会增加（因为它们正在等待）。这本质上意味着一段时间后，将出现另一个等待时间最长的任务（最需要 CPU），并且当前正在运行的任务将被抢占。使用这一原则，CFS 尝试公平对待所有任务，并始终尝试让系统的每个进程的等待时间为零\xe2\x80\x94每个进程都拥有相等的 CPU 份额（类似于\n \ xe2\x80\x9c 理想、精确、多任务 CPU\xe2\x80\x9d 就可以完成）。

\n

\n\n

虽然我还没有深入研究 Linux 内核源代码来了解该算法的实际工作原理，但我确实有一些猜测，我想提出一些关于共享/请求和配额/限制如何在此 CFS 中发挥作用的猜测。算法。

\n\n

首先，我的直觉让我相信，不同的进程/任务wait_runtime根据其分配的 CPU 份额/​​请求以不同的相对速率累积，因为维基百科声称 CFS 是加权公平队列的实现，这似乎是实现份额的合理方法。在尝试最小化wait_runtime所有进程/任务的算法上下文中基于/请求的权重。我知道这并没有直接回答所提出的问题，但我想确保我的解释作为一个整体对于份额/请求和配额/限制这两个概念都有用处。

\n\n

其次，关于配额/限制，我凭直觉认为这些适用于进程/任务在wait_runtime等待 I/O 时积累了不成比例的大数据的情况。还记得上面引用的 CFP 描述优先考虑最大的流程/任务吗wait_runtime？如果给定进程/任务没有配额/限制，那么在我看来，该进程/任务上的 CPU 使用率激增就会产生影响，只要它减少到wait_runtime足以使另一个任务允许抢占它，阻止所有其他进程/任务的执行。

\n\n

换句话说，Docker/Kubernetes 中的 CPU 配额/限制是一种机制，允许给定的容器/pod/进程在等待 I/O（而不是 CPU）后爆发 CPU 活动，从而赶上其他进程，而无需等待 I/O（而不是 CPU）。这样做的过程中不公平地阻止其他进程也在做工作。

\n