我在 EKS 节点上运行一个 pod,有 2500m 的请求且没有限制 - 它通常使用大约 3000m。我想测试请求是否真的得到保证,所以我在同一个节点上运行一个CPU压力测试pod,有3000m的请求,再次没有限制。
这导致原始 Pod 无法使用超过 ~1500m 的 CPU - 远低于其请求。然后当我关闭压力舱时,它又恢复使用 3000m。
有许多 Kubernetes 网页都说请求是 Pod 所“保证”的——但这仅仅意味着保证调度,还是实际上应该是保证。如果可以保证,为什么我的 Pod CPU 使用率会受到限制(请注意,Pod 不会受到无限制的限制)。
请求并不能保证资源(尤其是 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 被 Evicted 并重新调度到不同的节点上;被驱逐的 Pod 是超出其资源请求最多的 Pod。内存还可能导致节点耗尽物理内存,并且 Pod 可能会出现 OOMKilled。
如果每个pod 将资源请求和限制设置为相同的值,那么您确实可以大致保证资源可用,因为没有任何东西能够使用比 pod 调度程序分配的资源更多的资源。对于单个 pod 和非 CPU 资源,如果资源请求和限制相同,则在节点过度使用时您的 pod 不会被驱逐(因为它不能超过其请求)。另一方面,大多数进程通常不会完全使用它们的资源请求,因此将请求设置得足够高以确保您不会被驱逐也意味着您会导致节点拥有未使用的资源,并且您的集群作为整体效率会较低(需要更多节点来完成相同的工作并且成本更高)(但更可靠,因为 Pod 不会经常被杀死)。
| 归档时间: |
|
| 查看次数: |
1119 次 |
| 最近记录: |