Question

多年来在裸机上运行节点/ rails应用程序;我习惯于在一台机器上运行尽可能多的应用程序（让我们说，数字海洋的2Go可以轻松处理10个应用程序而不用担心，基于正确的优化或相当低的流量）

事情是，使用kubernetes，游戏听起来完全不同。我已经开始设置＆＃34;开始使用＆＃34;具有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％的最小部分。然后我觉得我误解了某些东西，或者误用了所有东西

感谢任何经验丰富的建议/建议，以便更好地理解最好

Answer 1

根据docs，CPU请求（和限制）始终是调度pod的节点上可用CPU核心的一小部分（resources.requests.cpu "1"意味着保留一个CPU核心专用于一个pod）。允许使用分数，因此"0.5"的CPU请求将为一个pod保留半个CPU。

为方便起见，Kubernetes允许您在毫秒中指定CPU资源请求/限制：

表达式0.1相当于表达式100m，可以读作“100 millupu”（有些可能会说“100毫微”），这被理解为同样的事情在谈论Kubernetes时）。带有小数点的请求（例如0.1）会被API转换为100m，并且不允许精确到1m的精度。

正如在另一个答案中已经提到的，资源请求是保证。这意味着Kubernetes将以一种所有请求的总和不会超过节点上实际可用资源量的方式安排pod。

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

Answer 2

6％的CPU意味着6％（CPU请求）的节点CPU时间是为此pod保留的。所以它保证它总能获得这个CPU时间。如果仍有CPU时间，它仍然可以突然达到12％（CPU限制）。

这意味着如果限制非常低，您的应用程序将需要更多时间来启动。因此，liveness probe可能会在它准备好之前杀死它，因为应用程序花了太长时间。要解决此问题，您可能需要增加活跃度探测的initialDelaySeconds或timeoutSeconds。

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

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

因此百分比会告诉您pod分配的总资源的CPU和内存量。

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

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

如果你的pod使用的内存超过限制中定义的内存，则会获得OOMKilled（内存不足）。
如果你的pod使用的内存多于请求中定义的内存，并且节点运行我们的内存，那么pod可能会被OOMKilled以保证其他pod能够存活，这比使用的内存要少。
如果您的应用程序需要的CPU多于请求的数量，则可以突然达到极限。
你的pod永远不会被杀死，因为它使用了太多的CPU。

kubernetes /了解CPU资源限制

2 个答案: