Kubernetes的请求真的有保证吗？

Question

我在一个EKS节点上运行一个pod，有2500万个请求，没有限制——它通常使用3000万个左右。我想测试请求是否真的得到了保证，所以我在同一个节点上运行了一个CPU压力测试盒，有3000万个请求，并且再次没有限制。

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

有很多Kubernetes的网页都说，请求是pod“保证”的内容，但这仅仅意味着对调度的保证，还是应该是一种保证。如果有保证，为什么我的pod CPU使用会受到限制（请注意，pod没有限制）。

Answer 1

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

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

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

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

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