我深入了解Kubernetes的资源限制，并且很难理解CPU limits的用途。我知道Kubernetes将requests和limits传递给（在我的情况下）Docker运行时。
示例：我有1个节点，1个CPU和2个Pod，CPU requests: 500m和limits: 800m。在Docker中，这导致（500m -> 0.5 * 1024 = 512）--cpu-shares=512和（800m -> 800 * 100）--cpu-quota=80000。 pod由Kube调度程序分配，因为requests总和不超过节点容量的100％;就limits而言，节点是过度的。
以上允许每个容器每100ms周期获得80ms的CPU时间（默认值）。一旦CPU使用率为100％，CPU时间就会根据其权重在容器之间共享，以CPU份额表示。根据1024的基值和每个512的份额，每个容器的50％。在这一点 - 根据我的理解 - limits没有更多的相关性，因为没有一个容器可以再获得它的80ms。他们都会得到50毫秒。因此，无论我定义了多少limits，当使用率达到临界值100％时，无论如何它都被requests分区。
这让我想知道：为什么我要首先定义CPU limits，并且过度使用会有什么不同吗？另一方面，requests在“当一切都在使用时我可获得多少份额”时完全可以理解。
通过使CPU限制大于CPU请求，您可以完成两件事：
- Pod可以进行突发活动，利用恰好可用的CPU资源。
- Pod在突发期间可以使用的CPU资源量限制在一些合理的数量。
我想这可能让我们想知道为什么我们关心将突发限制为“一些合理的数量”，因为它可以突发的事实似乎似乎表明当时没有其他进程竞争CPU。但我发现自己对这种推理不满意......
首先，我检查了你提到的docker标志的命令行帮助：
--cpu-quota int Limit CPU CFS (Completely Fair Scheduler) quota
-c, --cpu-shares int CPU shares (relative weight)
对Linux Completely Fair Scheduler的引用意味着为了理解CPU限制/配额的值，我们需要了解底层进程调度算法的工作原理。有道理，对吗？我的直觉是，它不像根据CPU份额/请求对CPU执行进行时间分割那么简单，并且在先到先得的基础上在一些固定时间片的末尾分配剩余的东西。
我发现this old Linux Journal article片段似乎是对CFS如何工作的合理描述：
CFS尝试跟踪系统中每个进程可用的CPU的公平份额。因此，CFS以实际CPU时钟速度的一小部分运行一个公平的时钟。公平时钟的增长率是通过将墙壁时间（以纳秒为单位）除以等待的进程总数来计算的。结果值是每个进程有权获得的CPU时间量。
当进程等待CPU时，调度程序会跟踪它在理想处理器上使用的时间。此等待时间由每任务wait_runtime变量表示，用于对调度进程进行排名，并确定在被抢占之前允许进程执行的时间。调度程序选择具有最长等待时间（即最大程度需要CPU）的进程并将其分配给CPU。当此进程运行时，其等待时间减少，而其他等待任务的时间增加（因为它们正在等待）。这实际上意味着在一段时间之后，将有另一个具有最大等待时间的任务（最严重的CPU需求），并且当前正在运行的任务将被抢占。使用这个原则，CFS试图对所有任务公平，并且总是试图使每个进程的等待时间为零的系统 - 每个进程具有相同的CPU份额（“理想，精确，多任务CPU”将完成的事情） ）。
虽然我没有深入研究Linux内核源代码以了解该算法是如何工作的，但我确实想要提出一些关于共享/请求和配额/限制如何影响此CFS算法的猜测。
首先，我的直觉让我相信不同的流程/任务根据他们分配的CPU份额/请求以不同的相对速率累积wait_runtime，因为Wikipedia claims that CFS is an implementation of weighted fair queuing这似乎是在一个上下文中实现基于份额/请求的权重的合理方式。尝试最小化所有进程/任务的wait_runtime的算法。我知道这并没有直接提到被问到的问题，但我想确保我的整体解释对于共享/请求和配额/限制这两个概念都有一席之地。
第二，关于配额/限制，我直觉认为这些适用于过程/任务在等待I / O时累积了不成比例的大wait_runtime的情况。请记住，上面引用的CFP描述优先考虑具有最大wait_runtime的过程/任务？如果在给定的进程/任务上没有配额/限制，那么在我看来，就像该进程/任务上的CPU使用率的爆发一样，只要它的wait_runtime足够减少另一个任务允许抢占它，阻止执行所有其他进程/任务。
换句话说，Docker / Kubernetes中的CPU配额/限制是一种机制，允许给定的容器/ pod /进程在CPU活动中突发以在等待I / O（而不是CPU）之后执行赶上其他进程在这样做的过程中不公平地阻止其他进程也在做工作。
设置CPU限制的一个原因是，如果设置CPU请求==限制和内存请求==限制，则会为您的pod分配一个Quality of Service class = Guaranteed，which makes it less likely to be OOMKilled if the node runs out of memory。在这里，我引用Kubernetes doc Configure Quality of Service for Pods：
为Pod提供保证的QoS等级：
- Pod中的每个Container必须具有内存限制和内存请求，并且它们必须相同。
- Pod中的每个Container必须具有CPU限制和CPU请求，并且它们必须相同。
使用Guaranteed QoS类的另一个好处是它允许您锁定pod的独占CPU，这对某些类型的低延迟程序至关重要。来自Control CPU Management Policies的报价：
staticCPU管理策略允许Guaranteedpod中的容器使用整数CPUrequests访问节点上的独占CPU。 ...只有同时属于Guaranteedpod且具有整数CPUrequests的容器才会被分配独占CPU。