kubernetes / 了解 CPU 资源限制

Question

来自多年在裸机上运行 node/rails 应用程序；我曾经能够在一台机器上运行任意数量的应用程序（假设基于正确的优化或相当低的流量，数字海洋中的 2Go 可以轻松处理 10 个应用程序而无需担心）

问题是，使用 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 的百分比。那么，20% 的 3.75Go 机器？那么这 6% 是从哪里来的呢？

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

仍然想知道这部分要考虑的指标是什么。

该应用在启动时似乎需要大量内存，但随后它只使用了这 6% 的一小部分。然后我觉得我误解了某些东西，或者误用了它

感谢您提供任何有经验的提示/建议以更好地理解 最好的

Answer 1

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

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

表达式0.1等价于表达式100m，可以读作“一百毫核”（有人可能会说“一百毫核”，这在谈到Kubernetes时理解为同一个意思）。带有小数点的请求，如0.1，通过API 转换为100m，并且不允许比1m 更精细的精度。

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

因此，通过在部署中请求64m 的 CPU 时间，您实际上是在请求节点的 CPU 核心时间之一的 64/1000 = 0,064 = 6,4%。这就是你的 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 可能会在 Pod 准备好之前将其杀死，因为应用程序花费了太长时间。要解决这个问题，您可能需要增加 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 能够生存，这些 pod 使用的内存少于其请求的内存。
• 如果您的应用程序需要比请求更多的 CPU，它可能会达到极限。
• 您的 pod 永远不会被杀死，因为它使用了过多的 CPU。