kubernetes - 在 kubernetes/openshift 中请求与限制 CPU

Question

我在为 Openshift 中的 pod 选择正确的请求和限制设置时遇到了一些困境。一些数据:

在启动期间，应用程序至少需要 600 毫核才能在 150 秒内完成就绪检查。

启动后，200 毫核应该足以让应用程序保持空闲状态。

所以我对文档的理解:

CPU 请求

Each container in a pod can specify the amount of CPU it requests on a node. The scheduler uses CPU requests to find a node with an appropriate fit for a container. The CPU request represents a minimum amount of CPU that your container may consume, but if there is no contention for CPU, it can use all available CPU on the node. If there is CPU contention on the node, CPU requests provide a relative weight across all containers on the system for how much CPU time the container may use. On the node, CPU requests map to Kernel CFS shares to enforce this behavior.

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

所以我应该去吗

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

为保证资源或

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

为了更好地节省 CPU

Answer 1

我认为您没有了解请求与限制的概念，我建议您查看 docs在你做出这个决定之前。

在简要说明中，

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

限时简单来说，就是在因为消耗太多资源而关闭之前，容器可以消耗多少，请求+从其他容器借用。

如果容器超出其内存 限制 ，它可能会被终止。

如果容器超出其内存 请求 ，每当节点内存不足时，它的 Pod 很可能会被驱逐。

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

docker docs中也有一个不错的帖子关于资源限制。

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

执行 规则有点不同:

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

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

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

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

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