当在特定节点上调度Kubernetes Pod时，该Pod需要有足够的资源来运行。Kubernetes知道它的节点的资源，但是Kubernetes如何知道Pod预先需要多少资源才能在节点中有效地调度它。为此，将使用requests。当我们指定资源的request时，Kubernetes将保证Pod将获得该数量的资源。

另一方面，limit限制了Pod的资源使用。Kubernetes不允许Pod占用比limit更多的资源。在CPU方面，如果您请求更多的CPU，Kubernetes会人为地对Pod CPU进行油门。如果Pod超过limit Pod，它将被终止。为了简单起见，limit总是大于request。

本例将让您了解request和limit。假设有一个Pod，其中您将其内存请求指定为7 GB，将内存限制指定为10 GB。集群中有三个节点，其中node1有2 GB内存，node2有8 GB内存，node3有16 GB内存。您的Pod永远不会被安排在node1上。但它将在节点2或节点3上调度，具体取决于Pod当前的内存使用情况。但是如果它被安排在node3上，那么它在任何情况下都将被终止，它将超过10 GB的内存使用量。

简而言之：对于CPU和内存请求：当调度器调度您的Pod时，K8保证您声明将获得的内容。

对于CPU和内存限制：K8保证您不会超过您设置的值。

当您的Pod超出限制时的结果：

• 对于CPU：K8限制您的容器
• 为了记忆：OOM，K8杀了你的豆荚

记忆是一种微不足道的理解。requests是有保证的，limits是不能超过的。这也意味着，例如，当您发出kubectl describe nodes | tail -10时，您可能会看到这样的短语：

"Total limits may be over 100 percent, i.e., overcommitted".

这意味着requests.memory的总和<=100%(否则无法调度Pod，这就是保证内存的含义)。同时，如果您看到的值*高于100%，则意味着limits.memory的总和可以超过100%(这是消息中过度承诺的部分)。因此，当节点尝试调度Pod时，它将只检查requests.memory以查看它是否有足够的内存。

CPU部分更复杂。

requests.cpu转换为CPU共享，如果不查看节点上的所有pod，老实说，它可能没有什么意义。要理解这个属性，最简单的方法就是看一个例子。

• 假设一个节点上有100个可用核，您部署单个示例并设置requests.cpu = 1000m。在这种情况下，您的Pod可以使用100个CPU，BOT最小和最大。
• 您有相同的机器(100核)，但您使用requests.cpu = 1000m部署了两个示例。在这种情况下，您的示例最少可以使用50核，最大可以使用100核。
• 相同节点，4个示例(requests.cpu = 1000m)。每个Pod最少可使用25个CPU，最大可使用100个CPU。

你明白了，重要的是requests.cpu的所有吊舱设置了什么才能得到整体情况。

limits.cpu要有趣得多，它转换为cgroup上的两个属性：cpu period和cpu quota。它意味着在一定的时间范围(期间)内你可以得到多少时间(配额)。这里的一个例子也会让事情变得更简单。

• 假设period=100ms和quota=20ms，您收到的请求将在Pod上以50ms结束。

它看起来是这样的：

|     100ms   ||     100ms   ||     100ms   |
| 20 ms ......|| 20 ms ......|| 10 ms ......|

因为处理请求需要50ms，而每个100ms只有20ms可用，所以总共需要300ms来处理我们的请求。

也就是说，有相当多的人建议根本不设置CPU。谷歌工程师、Zalando、Monzo等--包括我们。我们不这样做，这是有充分理由的(这超出了这个问题的范围)。

概念

• 容器指定一个请求，即系统保证给容器的资源量
• 容器指定了一个限制，即系统允许容器使用的最大数量。

Kubernetes上CPU限制和请求的最佳实践

• 一切都使用CPU请求，并确保它们是准确的
• 不要不要使用CPU限制。

Kubernetes上的内存限制和请求的最佳实践

• 使用内存限制和内存请求
• 设置内存限制=内存请求

有关限制和请求设置的更多详细信息，请参阅this answer

详情

• 容器可以指定资源请求和限制，0 <= request <= Node Allocatable和request <= limit <= Infinity

• 如果示例调度成功，则保证容器达到请求的资源量。调度基于requests和不是limits

• 容器和容器不允许超过指定的limit。如何强制执行请求和限制取决于资源是compressible还是incompressible

• 可压缩的资源保证

• Pod保证获得它们请求的CPU数量，它们可能会也可能不会获得额外的CPU时间(取决于正在运行的其他作业)。这一点目前还不能完全保证，因为CPU隔离是在容器级别。为了实现这一目标，不久将引入Pod级cgroup。

• 多余的CPU资源将根据请求的CPU数量进行分配。例如，假设容器A请求600mCPU，容器B请求300mCPU。假设两个容器都试图尽可能多地使用CPU。然后，额外的100毫升CPU将以2：1的比例分配给A和B(实现将在后面的章节中讨论)。

• 豆荚如果超过限制将被扼杀。如果未指定限制，则Pod可以使用多余的CPU(如果可用)。

• 不可压缩的资源保证

• Pod将获得它们请求的内存量，如果它们超过它们的内存请求，它们可能会被杀死(如果其他Pod需要内存)，但如果Pod消耗的内存比请求的少，它们不会被杀死(除非系统任务或守护程序需要更多内存)。

• 当Pod使用的内存超过其限制时，在Pod的容器中使用最大内存量的进程将被内核终止。

目的

• Kubernetes根据Pod的要求为其提供不同级别的服务质量。需要可靠保持的Pod可以请求有保证的资源，而要求不那么严格的Pod可以使用更弱或没有保证的资源。

• 对于每个资源，我们将容器按优先级从高到低分为Guaranteed、Burstable和Best-Effort三个服务质量等级。“请求和限制”和“服务质量等级”之间的关系很微妙。

• 如果所有容器的所有资源都设置了limits和可选的requests(不等于0)，并且它们是相等的，则示例被归类为保证类。

• 如果跨一个或多个容器的一个或多个资源设置了requests和可选的limits(不等于0)，并且它们不相等，则示例被归类为可突发。如果未指定limits，则默认为节点容量。

• 如果没有为所有资源设置requests和limits，跨所有容器，则示例分类为尽力而为。

• 示例不会被扼杀如果无法满足CPU保证(例如系统任务或守护程序占用大量CPU)，则会暂时对其进行限制。

• 内存是一种不可压缩的资源，因此让我们来讨论一下内存管理的语义。

• 尽力而为**示例将被视为最低优先级。如果系统内存不足，这些Pod中的进程将最先被终止。不过，这些容器可以使用节点中任何数量的空闲内存。

• 保证示例**被视为最高优先级示例，保证在超出其限制之前不会被销毁，或者如果系统处于内存压力下并且没有较低优先级的容器可以被驱逐。

• 可突发**示例具有某种形式的最低资源保障，但在可用时可以使用更多资源。在系统内存压力下，这些容器一旦超过其请求并且不存在尽力而为Pod，就更有可能被终止。

资料来源：Kubernetes的资源服务质量