在Kubernates / OpenShift中请求vs限制CPU

时间:2019-02-22 02:51:07

标签: kubernetes openshift

在为Openshift中的广告连播选择正确的请求和限制设置时,我遇到了一些难题。一些数据:

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

所以我对文档的理解:

CPU请求

  

pod中的每个容器都可以指定其在节点上请求的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

1 个答案:

答案 0 :(得分:4)

我认为您不了解请求与限制,建议您在做出决定之前先看看docs

简要说明,

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

限制是简单的术语,指的是在容器因消耗过多资源而关闭之前,该容器可以消耗多少,向其他容器请求+借用。

  1. 如果容器超出其内存 限制 ,它将可能终止。
  2. 如果容器超出其内存 request ,则很可能只要节点用完了,其Pod都将被驱逐记忆力

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

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

调度规则对于CPU和内存是相同的,如果节点可分配的CPU和内存足以容纳请求的所有资源,则K8只会将POD分配给该节点。容器中的容器。

执行规则有点不同:

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

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

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

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

PS:我引用了“借用”和“索回”的用语,因为该容器实际上并不是从另一个容器借用的,通常,该节点具有一个内存池,当它们被使用时,会为您提供大部分的内存需要它,因此从技术上讲,内存不是从容器中借来的,而是从池中借来的。