簡體   English   中英

Kubernetes 請求真的有保障嗎?

[英]Are Kubernetes requests really guaranteed?

我正在 EKS 節點上運行一個 pod,請求數為 2500m,沒有限制——它通常很樂意使用大約 3000m。 我想測試請求是否真的有保證,所以我在同一個節點上運行了一個 CPU 壓力測試 pod,有 3000m 的請求,並且再次沒有限制。

這導致原始 pod 無法使用超過約 1500 米的 CPU - 遠低於它的請求。 然后當我關閉壓力艙時,它又恢復使用 3000m。

有許多 Kubernetes 網頁說請求是 pod 的“保證”——但這是否僅意味着保證調度,或者它實際上應該是一種保證。 如果可以保證,為什么我的 pod CPU 使用率會受到限制(注意 pod 沒有無限制的節流)。

請求並不能保證資源(尤其是 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 不會經常被殺死)。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM