Pod CPU 節流

Question

在 Kubernetes 中使用CPU Requests/Limits時遇到一個奇怪的問題。 在設置任何 CPU 請求/限制之前，我所有的服務都表現得非常好。 我最近開始放置一些資源配額以避免未來的資源匱乏。 這些值是根據這些服務的實際使用情況設置的，但令我驚訝的是，在添加這些值之后，一些服務的響應時間開始急劇增加。 我的第一個猜測是我可能放置了錯誤的請求/限制，但查看指標發現實際上面臨此問題的服務都沒有接近這些值。 事實上，其中一些更接近請求而不是限制。

然后我開始查看 CPU 節流指標，發現我所有的 pod 都被節流了。 然后我將其中一項服務的限制增加到 1000m（從 250m），我看到那個 pod 中的節流減少了，但我不明白如果 pod 沒有達到它的舊限制（250m），為什么我應該設置更高的限制）。

所以我的問題是：如果我沒有達到 CPU 限制，為什么我的 Pod 會節流？ 如果 Pod 沒有使用其全部容量，為什么我的響應時間會增加？

這里有一些我的指標截圖（CPU 請求：50m，CPU 限制：250m） ：

CPU 使用率（在這里我們可以看到這個 pod 的 CPU 從未達到其 250m 的限制）：

CPU 節流：

將此 pod 的限制設置為1000m 后，我們可以觀察到更少的節流

kubectl 頂部

PS：在設置這些請求/限制之前，根本沒有節流（正如預期的那樣）

PS 2：我的節點都沒有面臨高使用率。 事實上，他們中沒有人在任何時候使用超過 50% 的 CPU。

提前致謝！

Answer 1

如果您看到在發出 CPU Request時看到的文檔，它實際上使用 Docker 中的--cpu-shares選項，該選項實際上使用 cpu.shares 屬性作為 Linux 上的cpu,cpuacct cgroup 。 所以50m的值大約是--cpu-shares=51基於最大值1024 。 1024代表 100% 的份額，因此51將是 4-5% 的份額。 這是相當低的，開始。 但這里的重要因素是，這與您系統上有多少個 pod/容器以及它們擁有的 cpu 共享（它們是否使用默認值）有關。

因此，假設在您的節點上，您有另一個具有 1024 個共享的 pod/容器，這是默認值，並且您有這個具有 4-5 個共享的 pod/容器。 然后這個容器將獲得大約 0.5% 的 CPU，而另一個 pod/容器將獲得大約 99.5% 的 CPU（如果它沒有限制）。 因此，這一切都取決於您在節點上擁有多少個 pod/容器以及它們的份額是多少。

此外，在Kubernetes 文檔中沒有很好地記錄，但是如果您在 pod 上使用Limit ，它基本上在 Docker 中使用兩個標志：-- --cpu-period and --cpu--quota ，它們實際上使用 cpu.cfs_period_us 和 cpu。 Linux 上cpu、cpuacct cgroup 的cfs_quota_us 屬性。 這是因為 cpu.shares 沒有提供限制，所以你會溢出容器會占用大部分 CPU 的情況。

因此，就此限制而言，如果您在同一節點上有其他沒有限制（或更高限制）但具有更高 cpu.shares 的容器，您將永遠不會達到它，因為它們最終會優化並選擇空閑中央處理器。 這可能是您所看到的，但同樣取決於您的具體情況。

此處對以上所有內容進行了更長的解釋。

Answer 2

Kubernetes 使用（完全公平調度程序）CFS 配額對 pod 容器實施 CPU 限制。 有關更多詳細信息，請參閱https://kubernetes.io/blog/2018/07/24/feature-highlight-cpu-manager/ 中描述的“CPU Manager 如何工作”。

CFS是Linux的一個特性，是2.6.23內核加入的，它基於兩個參數：cpu.cfs_period_us 和cpu.cfs_quota 為了形象化這兩個參數，我想借用Daniele Polencic的下圖博客（ https://twitter.com/danielepolencic/status/1267745860256841731 ）：

如果您在 K8s 中配置 CPU 限制，它將設置周期和配額。 如果在容器中運行的進程達到限制，它將被搶占並必須等待下一個時期。 它被節流了。 所以這就是你正在體驗的效果。 周期和配額算法不應被視為 CPU 限制，如果未達到，進程將不受限制。 該行為是令人費解，也K8S問題存在此： https://github.com/kubernetes/kubernetes/issues/67577中給出的建議https://github.com/kubernetes/kubernetes/issues/51135是不要為不應受到限制的 pod 設置 CPU 限制。

Answer 3

TLDR：刪除您的 CPU 限制。 （ 除非此警報在metrics-server上觸發，在這種情況下將無法工作。 ）CPU 限制實際上是一種不良做法，而不是最佳做法。

為什么會發生這種情況

我將專注於要做什么，但首先讓我舉一個簡單的例子來說明為什么會發生這種情況：

1. 想象一個 CPU 限制為 100m 的 pod，相當於 1/10 vCPU。
2. Pod 在 10 分鍾內什么都不做。
3. 然后它使用 CPU 不間斷地運行 200 毫秒。 突發期間的使用量相當於 2/10 vCPU，因此 pod 超出了它的限制並將被限制。
4. 另一方面，平均 CPU 使用率將非常低。

在這種情況下，您將受到限制，但突發非常小（200 毫秒），以至於不會出現在任何圖表中。

該怎么辦

在大多數情況下，您實際上不想要 CPU 限制，因為它們會阻止 pod 使用備用資源。 有記錄的 Kubernetes 維護者說你不應該使用 CPU 限制，而應該只設置請求。

更多信息

我寫了一個完整的 wiki 頁面， 說明為什么在CPU 使用率低的情況下仍會發生 CPU 節流以及如何處理。 我還討論了一些常見的邊緣情況，例如如何為不遵循通常規則的metrics-server處理此問題。