在Kubernates / OpenShift中请求vs限制CPU

Question

我在为Openshift中的吊舱选择正确的请求和限制设置方面遇到一些难题。一些数据：

1. 在启动期间，该应用程序至少需要6亿核，才能在150秒内完成就绪检查。
2. 启动后，200百万个内核应该足以使应用程序保持空闲状态。

所以我对文档的理解是：

CPU请求

容器中的每个容器都可以指定其在节点上请求的CPU数量。调度程序使用CPU请求来查找适合容器的节点。CPU请求代表您的容器可以消耗的最小CPU数量，但是如果没有CPU争用，它可以使用节点上所有可用的CPU。如果节点上存在CPU争用，则CPU请求会在系统上所有容器上提供一个相对权重，以表示该容器可以使用多少CPU时间。在该节点上，CPU请求映射到内核CFS共享以强制执行此行为。

请注意，调度程序将引用请求CPU在节点上执行分配，然后一旦分配，它便是保证资源。同样在另一侧，我可能分配了额外的CPU，因为可能仅在启动期间需要600 mil。

所以我应该去

resources:
    limits:
      cpu: 1
    requests:
      cpu: 600m

用于担保资源或

resources:
    limits:
      cpu: 1
    requests:
      cpu: 200m 

更好地节省CPU

Answer 1

我认为您不了解Requests vs Limits的概念，建议您在决定之前先阅读一下文档。

简要说明一下

请求是将虚拟地分配给容器多少资源，它保证您可以在需要时使用它，并不意味着它专门保留给容器。话虽如此，如果您请求200mb的RAM但仅使用100mb，则其他100mb将在其他容器消耗所有请求的内存时“借用”，并在您的容器需要它时“收回”。

限制很简单，就是容器在由于消耗过多资源而被关闭之前，可以消耗多少，从其他容器请求并借用其他容器。

1. 如果容器超出其内存限制，则可能会终止。
2. 如果Container超出其内存请求，则当节点内存不足时，很可能将其Pod逐出。

简单来说，限制是一个绝对值，它应该等于或大于请求，并且良好的做法是仅在某些工作负载可能需要限制的情况下，避免所有容器的限制都高于请求。因为大多数容器消耗的资源（即内存）多于请求的资源，所以突然会以一种无法预测的方式将POD从节点中逐出，这比每个容器都有固定的限制更糟。

docker docs中还有一篇关于资源限制的好文章。

CPU和内存的调度规则是相同的，如果节点具有可分配的足够CPU和内存以适合容器中容器所需的所有资源，则K8只会将POD分配给该节点。

在执行规则是有点不同：

内存是节点中的有限资源，容量是绝对限制，容器消耗的内存不能超过节点的容量。

另一方面，CPU以CPU时间来度量，当您保留CPU容量时，您将告诉容器可以使用多少CPU时间，如果容器需要的时间比请求的时间长，则可以对其进行限制并执行排队直到其他容器耗尽了分配的时间或完成了工作。总而言之，它与内存非常相似，但是容器不太可能因为消耗过多的CPU而被杀死。当其他容器未使用分配给它们的全部CPU时间时，该容器将能够使用更多的CPU。主要问题是，当容器使用的CPU比分配的CPU多时，节流将降低应用程序的性能，并在某些时候停止正常工作。如果不提供限制，则容器将开始影响节点中的其他资源。

关于要使用的值，没有正确的值或正确的公式，每个应用程序都需要不同的方法，只需多次测量就可以找到正确的值，我给您的建议是确定最小值和最大值并进行调整在中间的某个位置，然后继续监视以查看其行为，如果您感觉正在浪费\缺少资源，则可以减少\增加到最佳值。如果服务至关重要，请从更高的价值开始，然后再减少。

对于准备情况检查，不应将其用作指定这些值的参数，可以initialDelaySeconds在探针中使用参数延迟准备情况，以留出更多时间启动POD容器。

PS：我引用了“借用”和“索回”这两个术语，因为该容器实际上并不是从另一个容器借用的，通常，该节点具有一个内存池，并在需要时为您提供大部分的内存给容器，因此，从技术上讲，内存不是从容器而是从池中借用的。