请求与限制 kubernetes/openshift 中的 cpu

Question

在为 Openshift 中的 pod 选择正确的请求和限制设置时，我遇到了一些难题。部分数据：

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

所以我对文档的理解：

CPU 请求

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

需要注意的是，调度器会参考请求的CPU对节点进行分配，一旦分配，就是保证资源。 另一方面，我可能会分配额外的 CPU，因为 600 毫核可能仅在启动期间需要。

所以我应该去

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

保证资源或

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

为了更好地节省 CPU

Answer 1

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

简要说明，

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

限制是简单的术语，是容器可以消耗多少，请求+从其他容器借用，然后因为消耗太多资源而关闭。

1. 如果 Container 超出其内存限制，它将可能被终止。
2. 如果 Container 超出其内存 request，则很可能每当 节点用完时，其 Pod 就会被驱逐记忆。

简单来说，limit是一个绝对值，应该等于或高于request，最好的做法是避免所有容器的limit都高于request，只有在某些工作负载可能需要它的情况下，这是因为大多数容器消耗的资源（即：内存）比它们请求的要多，突然间，POD 将开始以不可预测的方式从节点中逐出，这比如果每个都有一个固定的限制。

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

调度规则对于 CPU 和内存是相同的，K8s 只会在节点有足够的 CPU 和内存可分配以适应所有资源请求分配一个 POD 给节点strong> 由 pod 中的容器组成。

执行规则有点不同：

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

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

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

对于就绪检查，您不应将其用作指定这些值的参数，您可以使用探针中的initialDelaySeconds 参数延迟就绪，以提供额外的时间来启动 POD 容器。

PS：我引用了“借用”和“收回”这两个术语，因为容器实际上并没有从另一个容器借用，一般来说，节点有一个内存池，并且当他们需要它，所以从技术上讲，内存不是从容器中借来的，而是从池中借来的。