Kubernetes 请求真的有保障吗？

Question

我正在 EKS 节点上运行一个 pod，请求数为 2500m，没有限制——它通常很乐意使用大约 3000m。 我想测试请求是否真的有保证，所以我在同一个节点上运行了一个 CPU 压力测试 pod，有 3000m 的请求，并且再次没有限制。

这导致原始 pod 无法使用超过约 1500 米的 CPU - 远低于它的请求。 然后当我关闭压力舱时，它又恢复使用 3000m。

有许多 Kubernetes 网页说请求是 pod 的“保证”——但这是否仅意味着保证调度，或者它实际上应该是一种保证。 如果可以保证，为什么我的 pod CPU 使用率会受到限制（注意 pod 没有无限制的节流）。

Answer 1

请求并不能保证资源（尤其是 CPU）在运行时可用。 如果您将请求和限制设置得非常接近，您会有更好的期望，但是您需要系统中的每个 Pod 进行合作才能有真正的保证。

资源请求只影响 Pod 的初始调度。 在您的示例中，您有一个请求 2.5 CPU 的 Pod 和请求 3 CPU 的第二个 Pod。 如果您的节点有 8 个 CPU，则两者可以调度在同一个节点上，但如果该节点只有 4 个 CPU，则它们需要在不同的节点上运行（如果您有集群自动缩放器，它可以创建一个新节点）。

继续这个例子，假设 pod 被安排在具有 8 个 CPU 的同一节点上。 既然他们已经被安排好了，资源请求就不再重要了。 两个 Pod 都没有资源限制，但假设较小的 Pod 实际上尝试使用 3 个 CPU，而较大的 Pod（多线程压力测试）使用 13 个 CPU。 这超过了系统的物理容量，因此内核会为这两个进程分配处理器周期。

对于 CPU 使用率，如果节点过度使用，您只会看到所有进程的速度变慢。 内存或磁盘（“临时存储”）都可能导致 pod 被驱逐并在不同节点上重新调度； 被驱逐的 pod 是那些超过其资源请求最多的 pod。 内存也可能导致节点耗尽物理内存，并且 pod 可能会被 OOMKilled。

如果每个pod 都将资源请求和限制设置为相同的值，那么您确实可以大致保证资源可用，因为没有什么能够使用比 pod 调度程序分配的资源更多的资源。 对于单个 pod 和非 CPU 资源，如果资源请求和限制相同，那么如果节点过度使用，您的 pod 不会被驱逐（因为它不能超过其请求）。 另一方面，大多数进程通常不会完全使用它们的资源请求，因此将请求设置得足够高以保证您不会被驱逐也意味着您导致节点具有未使用的资源，并且您的集群作为整体效率会降低（需要更多节点来完成相同的工作并且成本更高）（但更可靠，因为 pod 不会经常被杀死）。