kubernetes /了解CPU资源限制

来自多年来在裸机上运行节点/轨应用的应用程序;我曾经能够在单台机器上运行尽可能多的应用程序（比如说，数字海洋上的2Go可以轻松处理10个应用程序，而无需担心，基于正确的优化或相当低的通信量）kubernetes /了解CPU资源限制

事情是，使用kubernetes，游戏听起来完全不同。我已经用2个标准vm（3.75Go）设置了一个“入门”集群。

分配限制在部署有以下几点：

 resources: 
      requests: 
      cpu: "64m" 
      memory: "128Mi" 
      limits: 
      cpu: "128m" 
      memory: "256Mi"

然后看到以下内容：

Namespace  Name   CPU Requests CPU Limits Memory Requests Memory Limits 
---------  ----   ------------ ---------- --------------- ------------- 
default   api    64m (6%)  128m (12%) 128Mi (3%)  256Mi (6%)

是什么6％指的是？

试图降低CPU限制，喜欢，20Mi ...应用程序启动（显然，没有足够的资源）。文档说它是CPU的百分比。那么，3.75Go机器的20％？那么这6％来自哪里呢？

然后将节点池的大小增加到n1-standard-2，同一个pod有效地跨越节点的3％。这听起来合乎逻辑，但它实际上指的是什么？

不知道这部分的指标是什么。

该应用似乎需要大量的启动内存，但它只使用这个6％的一小部分。然后我觉得我误解的东西，或者滥用这一切

感谢任何经验的提示/建议有节点CPU有更好的了解最佳

来源

2017-02-19 Ben

如果你也发布'kubectl describe节点...'的表头，这将会很有帮助。 – svenwltr

@svenwltr那里是https://gist.github.com/bbnnt/36c1bfa463a9b03bad7f0ec2c945424c – Ben

CPU的6％，意味着6％（CPU请求）时间是为这个吊舱预留的。所以它保证它总是能够达到这个数量的CPU时间。如果仍有CPU时间，它仍然可以突发高达12％（CPU限制）。

这意味着如果限制非常低，您的应用程序将需要更多时间来启动。因此，liveness probe可能会在准备就绪之前终止该容器，因为该应用程序耗时过长。要解决此问题，您可能需要增加活动探测的initialDelaySeconds或timeoutSeconds。

另请注意，资源请求和限制定义了您的pod分配的资源量，而不是实际使用量。

资源请求是您的pod保证在节点上获得的内容。这意味着所请求资源的总和不得高于该节点上的CPU /内存总量。
资源限制是允许您使用pod的上限。这意味着这些资源的总和可以高于实际可用的CPU /内存。

因此，百分比会告诉您在pod分配的资源总量中有多少CPU和内存。

链接到文档：https://kubernetes.io/docs/user-guide/compute-resources/

其他一些值得注意的事项：

如果您的吊舱使用比限制规定更多的内存，它就会OOMKilled（内存不足）。
如果你的pod使用比请求中定义的内存更多的内存，并且节点运行我们的内存，那么该POD可能会获得OOMKilled，以保证其他的POD能够存活，而使用该请求的内存少于其请求的内存。
如果您的应用程序需要比请求更多的CPU，它可以突破最大限度。
你的pod永远不会被杀死，因为它使用了太多的CPU。

来源

2017-02-19 12:28:44 svenwltr

我本来可以更准确。在所示的例子中，CPU的6％，这有效地意味着什么？关于码头容器和运行应用程序，它是如何涉及的？如上所述，我降低到分配给cpu试用。它并不是很专业（正如我预料的那样），但是它一直在重新启动而没有有效地提升 – Ben

这是我听起来非常棘手的地方。只是再次降低了CPU（从64到20Mi，限制为40Mi）。 *没有oomkilled *。它只是重新启动，从来没有准备好。再次将它增加到我的问题中显示的值，就像它马上准备好的魅力一样。这对我来说是双倍的偏见，因为同样的情况发生在目前的 – Ben

的一半大小的机器上，除此之外，我如何评估应用程序的需求，然后相应地分配CPU？目前我只是不明白它与何处有关 – Ben

按照docs，CPU请求（和限制），总是存在吊舱被调度上的节点上可用的CPU内核的级分（用resources.requests.cpu的"1"含义预留用于一个吊舱仅仅一个CPU核的）。分数是允许的，因此CPU请求"0.5"将为一个吊舱保留一半的CPU。

为了方便起见，Kubernetes允许在millicores指定CPU的资源请求/限制：

表达0.1相当于表达100m，其可以被读作“百个millicpu”（一些可能会说“一百毫克”，而在谈到Kubernetes时，这被理解为同样的意思）。带有小数点的请求（如0.1）会被API转换为100m，并且不允许使用精度高于1m的精度。

正如在其他答案中已经提到的，资源请求是保证。这意味着Kubernetes将按照所有请求的总和不会超过节点上实际可用资源数量的方式安排窗格。

因此，通过在您的部署中请求64m CPU时间，您实际上请求节点的一个CPU核心时间的64/1000 = 0,064 = 6.4％。这就是你的6％来自哪里。当升级到具有更多CPU核心的虚拟机时，可用CPU资源的数量会增加，因此在具有两个可用CPU核心的计算机上，CPU时间的6.4％的请求将占用CPU的3.2％时间为两个 CPU。

来源

2017-02-19 13:37:34 helmbert

kubernetes /了解CPU资源限制

回答

相关问题