kubernetes/openshift 中的请求与限制 cpu

我在为 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

我认为你没有明白请求与限制，我建议您看一下docs https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#how-pods-with-resource-limits-are-run在你做出决定之前。

在简短的解释中，

Request是虚拟地分配给容器多少资源，它保证您需要时可以使用它，并不意味着它保留独占给容器。也就是说，如果您请求 200mb RAM 但只使用了 100mb，则其他 100mb 将在其他容器消耗完所有请求的内存时被“借用”，并在您的容器需要时“收回”。

Limit很简单，就是在因消耗过多资源而关闭之前，容器可以消耗多少、请求+从其他容器借用的量。

1. 如果容器超出其内存limit， 它会probably被终止。
2. 如果容器超出其内存request, it is likely每当节点内存不足.

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

里面还有一个不错的帖子码头工人文档 https://docs.docker.com/config/containers/resource_constraints/关于资源限制。

The 调度CPU 和内存的规则相同，如果节点有足够的 CPU 和内存可分配以适应所有资源，K8s 只会将 POD 分配给该节点要求的通过 pod 内的容器。

The 执行规则有点不同：

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

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

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

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

PS：我引用了“借用”和“收回”这两个术语，因为容器实际上并不是从另一个容器借用的，一般来说，节点有一个内存池，并在容器需要时将大块内存提供给容器，因此从技术上讲，内存不是从容器借来的，而是从池中借来的。