Kubernetes memory 限制：在同一個 pod 上有和沒有 memory 限制的容器

Question

我的 pod 有兩個容器（ PodA ）

第一個容器 ( C1 ) 具有以下限制

Limits:                                                                                                                                                                                                
  cpu:     2                                                                                                                                                                                           
  memory:  1Gi                                                                                                                                                                                         Requests:                                                                                        
  cpu:     100m                                                                                  
  memory:  128Mi

第二個容器 ( C2 ) 沒有指定請求/限制

我有以下問題

1. 從我使用kubectl describe nodes可以看出， PodA的內存/cpu 請求/限制與C1中的相同。 那是對的嗎？
2. C2的內存/cpu 限制是多少？ 是無界的嗎？ 受限於PodA的限制（例如C1的限制）？
3. #2 的跟進 -> 如果C2要求的 memory 超過 1Gi，會發生什么？ 容器會不會用完memory，導致整個pod崩潰？ 或者只要節點有空閑的memory，就可以搶到更多的memory？

我試圖用谷歌搜索，但我看到的所有示例都為兩個容器設置了資源限制

Answer 1

Kubernetes 根據您是否添加了請求和限制將您的 Pod 置於服務質量類中。

如果 pod 中的所有容器都設置了限制，則 pod 屬於Guaranteed class。

如果 pod 中的至少一個容器設置了請求（或限制），則該 pod 屬於Burstable class。

如果沒有為所有容器設置請求或限制，則 Pod 將屬於Best Effort class。

在您的示例中，您的 pod 屬於Burstable class 因為C2沒有設置限制。

---

這些請求和限制用於兩種情況 - 調度和資源耗盡。

調度

在調度過程中，根據可用資源考慮對 select 節點的請求。 limits可能會被過度使用，並且不會被考慮用於調度決策。

資源枯竭

您可以在兩個資源上指定請求和限制 - cpu 和 memory

CPU 是一種可壓縮資源，即 kernel 可以根據需要通過分配更少的 CPU 時間來限制進程的 CPU 使用率。 因此，如果其他進程處於空閑狀態，則允許一個進程使用盡可能多的 CPU。 如果另一個進程需要 cpu，操作系統可以為使用更多 CPU 的進程限制 cpu 時間。 未使用的 cpu 時間將按其請求的比例進行分配。 如果您不希望這種無限 cpu 使用的行為，即您希望您的容器不超過某個閾值，您可以設置限制。

Memory 不是可壓縮資源。 一旦分配給一個進程，kernel 就無法重新獲得 memory。 因此，如果設置了限制，如果進程嘗試使用超過限制，則會被 OOM 殺死。 如果沒有設置限制，進程可以根據需要分配任意數量，但如果 memory 耗盡，重新獲得一些空閑 memory 的唯一方法是終止進程。 這就是 QoS class 出現的地方。 BestEffort容器將是第一個被 OOM 殺死的容器。 下一個Burstable class 容器將在任何Guaranteed class 容器被殺死之前被殺死。 在容器具有相同 QoS class 的情況下，與其請求相比，使用更高百分比的 memory 的容器將被 OOM 殺死。

---

從我通過 kubectl describe 節點看到的情況來看，PodA 的內存/cpu 請求/限制與 C1 中的相同。 那是對的嗎？

是的

C2 的內存/cpu 限制是多少？ 是無界的嗎？ 受限於 PodA 的限制（例如 C1 的限制）？

CPU 作為可壓縮資源對於所有容器都是無限制的（如果指定了限制，則可以達到限制）。 當具有請求集的其他容器需要更多 cpu 時間時，C2 將受到限制。

#2 的跟進 -> 如果 C2 要求的 memory 超過 1Gi，會發生什么？ 容器會不會用完memory，導致整個pod崩潰？ 或者只要節點有空閑的memory，就可以搶到更多的memory？

它可以抓取盡可能多的 memory。 但是如果節點沒有更多的空閑 memory 可以分配給其他進程，它將是第一個被 OOM 殺死的節點。