眾所周知,Kubernetes QOS 分為三個級別：

• Guaranteed：Pod 里的每個容器都必須有內存/CPU 限制和請求，而且值必須相等。如果一個容器只指明limit而未設定request，則request的值等于limit值。
• Burstable：Pod 里至少有一個容器有內存或者 CPU 請求且不滿足 Guarantee 等級的要求，即內存/CPU 的值設置的不同。
• BestEffort：容器必須沒有任何內存或者 CPU 的限制或請求。

谷歌的最佳實踐告訴你，重要服務一定要配置 Guaranteed 的，這樣在資源不足的時候可以保證你的重要服務不被驅逐。

最佳實踐要求你這樣配置是從運維和后期運營的角度來說的，團隊剛起步，不設置資源請求和限制的情況下基本可以正常工作，但隨著團隊和項目的增長，您將開始遇到穩定性問題。服務之間相互影響，這時候可能需要為服務添加限制，并且可以讓您免于遇到許多令人頭疼的問題。

這里我們應該已經清楚，通過遵循最佳實踐，使整個集群具有更大的靈活性和可靠性。

但是當涉及到 CPU 限制時，事情就變得有趣了。CPU 是可壓縮資源。如果您的應用開始達到 CPU 限制，Kubernetes 就會開始限制您的容器。這意味著 CPU 將受到人為限制，使您的應用程序性能可能更差！

1. 為什么會這樣呢？

因為當你在容器編排器中設置硬 CPU 限制時，內核使用完全公平調度程序 (CFS) Cgroup來強制執行這些限制。CFS Cgroup 機制使用兩個設置來管理 CPU 分配：配額和周期。當應用程序在給定時間段內使用超過其分配的 CPU 配額時，它會受到限制，直到下一個時間段。

cgroup 的所有 CPU 指標都位于??/sys/fs/cgroup/cpu,cpuacct/<container>??. 配額和期間設置位于??cpu.cfs_quota_us??和中??cpu.cfs_period_us??。

您還可以查看限制指標 cpu.stat。在里面 cpu.stat 你會發現：

• nr_periods– cgroup 任何線程可運行的周期數
• nr_throttled– 應用程序使用其全部配額并受到限制的可運行周期數
• throttled_time– 控制 cgroup 中各個線程的總時間

2. 舉個簡單的例子

單線程應用程序在具有 cgroup 約束的 CPU 上運行。此應用程序需要 200 毫秒的處理時間來完成一個請求。不受約束，它的響應看起來如下圖。

沒有配置限制的請求

現在，假設我們為應用程序分配了 0.4 CPU 的 CPU 限制。這意味著應用程序每 100 毫秒周期獲得 40 毫秒的運行時間——即使這些時間 CPU 沒有其他工作要做。200 毫秒的請求現在需要 440 毫秒才能完成。

配置限制的請求

這個時候你查看下所在容器路徑下的 cpu.stat throttled_time 你會發現被限制了 240ms（對于每 100 毫秒的周期，應用程序只能運行 40 毫秒，并被限制 60 毫秒。它已被限制了 4 個周期，因此 4 * 60 = 240 毫秒。）

換一個通俗點的說法，當您要求 1 個 CPU 時，這意味著您的應用程序每秒可以使用 1 個 CPU 內核。如果它是一個單線程，它將能夠一直使用一個內核。但是，如果它有 2 個線程，則每秒可以無限制地使用 2 個核心秒。因此，有了這個限制，它可以在 1/2 秒內完全使用 2 個核心，然后會受到限制。（雖然這并不是真正以秒為單位來衡量的，實際是us，但我發現這樣更容易理解）。

看到這里，你可能會說，這只是一種約束，超出范圍的資源，就是不能使用，否則將被限制。

3. 是否存在不必要的限制

并沒有這么簡單，很多人反饋遭到了不必要的 cgroup 限制，甚至還沒有 CPU 上限，這里有激烈的討論：

1. ????https://github.com/kubernetes/kubernetes/issues/67577????
2. ????https://github.com/kubernetes/kubernetes/issues/51135????
3. ????https://github.com/kubernetes/kubernetes/issues/70585????
4. ????https://github.com/kubernetes/kubernetes/pull/75682????

運行容器時要檢查的關鍵指標是throttling. 這表明您的容器被限制的次數。我們發現很多容器無論 CPU 使用率是否接近極限都會受到限制。如下一個熱心網友反饋的案例：

在動畫中可以看到 CPU 限制設置為800m（0.8 個核心，80% 的核心），峰值使用率最高為200m（20% 的核心）。看到之后，我們可能會認為我們有足夠的 CPU 讓服務在它節流之前運行，對吧？. 現在看看這個：

即使 CPU 使用率低于 CPU 限制，您也會注意到發生了 CPU 限制。最大 CPU 使用率甚至沒有接近 CPU 限制。

限制就意味著服務性能下降和延遲增高。

4. 什么原因導致的呢？

本質上來說，這個問題是 linux 內核導致，具體可以看下這個視頻：????https://www.youtube.com/watch?v=UE7QX98-kO0????

這個視頻大概意思是這樣的。

這里有一個多線程守護進程的例子，它有兩個工作線程，每個工作線程都固定在自己的核心上。如下圖，第一個圖顯示了 cgroup 在一段時間內的全局配額。這從 20ms 的配額開始，這與 0.2 CPU 相關。中間的圖表顯示分配給每個 CPU 隊列的配額，底部的圖表顯示實際工作線程在其 CPU 上運行的時間。

在 10 毫秒：

• Worker 1 收到了一個請求。
• 一部分配額從全局配額轉移到 CPU 1 的每個 CPU 隊列。
• Worker 1 需要 5ms 來處理和響應請求。

在 17 毫秒：

• Worker 2 收到了一個請求。
• 一部分配額從全局配額轉移到 CPU 2 的每個 CPU 隊列。

Worker 1 需要精確 5 毫秒來響應請求的機會是非常不現實的。如果請求需要其他一些處理時間會發生什么？

在 30 毫秒：

• Worker 1 收到了一個請求。
• Worker 1 只需要 1 毫秒來處理請求，而 CPU 1 的每個 CPU 存儲桶上還剩下 4 毫秒。
• 由于每個 CPU 運行隊列上還有剩余時間，但 CPU 1 上沒有更多可運行線程，因此設置了一個計時器以將 slack 配額返回給全局存儲桶。這個定時器在worker 1停止運行后設置為7ms。

在 38 毫秒：

• CPU 1 上設置的 slack 計時器觸發并將除 1 ms 之外的所有配額返回到全局配額池。
• 這會在 CPU 1 上留下 1 毫秒的配額。

在 41 毫秒：

• Worker 2 收到一個長請求。
• 所有剩余時間都從全局存儲桶轉移到 CPU 2 的 per-CPU 存儲桶，Worker 2 使用所有時間。

在 49 毫秒：

• CPU 2 上的 Worker 2 現在在未完成請求的情況下受到限制。
• 盡管 CPU 1 仍有 1ms 的配額，但仍會發生這種情況。

雖然 1 毫秒可能對雙核機器沒有太大影響，但這些毫秒在高核數機器上加起來。如果我們在 88 核 (n) 機器上遇到此行為，我們可能會在每個周期內耗費 87 (n-1) 毫秒。那可能無法使用的 87 毫秒或 0.87 CPU（每個Container）。這就是我們通過過度節流來達到低配額使用的方式。在最好的情況下，如果修復，使受影響的應用程序的每個實例的可用 CPU 增加 0.87，或者所需的 CPU 配額相應減少。這些優勢將在我們的集群中提高應用程序密度并縮短應用程序響應時間。

當 8 核和 10 核機器這個問題基本上沒有引起注意。現在核心數量風靡一時，這個問題變得更加明顯。這就是為什么我們注意到在更高核心數的機器上運行同一應用程序時會增加限制。

總結來說，時鐘偏差限制問題，這導致每個時期的配額都受到嚴格限制。這個問題一直是存在的，至少自提交 512ac999 和內核 v4.18 以來，它就是這樣工作的。

5. linux 內核是如何解決這個問題

當且僅當每個 CPU 的過期時間與全局過期時間匹配時，預補丁代碼才會在運行時過期??cfs_rq->runtime_expires != cfs_b->runtime_expires??。通過檢測內核，我證明了這種情況在我的節點上幾乎從未出現過。因此，那 1 毫秒永不過期。該補丁將此邏輯從基于時鐘時間更改為周期序列計數，解決了內核中長期存在的錯誤。代碼如下：

- if (cfs_rq->runtime_expires != cfs_b->runtime_expires) { 
+ if (cfs_rq->expires_seq == cfs_b->expires_seq) { 
               /* 延長本地期限，漂移以 2 個滴答為界 */ 
                cfs_rq->runtime_expires + = TICK_NSEC; 
       } else { 
                /* 全局截止日期提前，過期已過 */ 
                cfs_rq->runtime_remaining = 0; 
        }

修改問題 5.4+ 主線內核的一部分。它們已被反向移植到許多可用的內核中：

1. RHEL 7: 3.10.0–1062.8.1.el7+
2. RHEL 8: 4.18.0–147.2.1.el8_1+

• Linux-stable: 4.14.154+, 4.19.84+, 5.3.9+
• Ubuntu: 4.15.0–67+, 5.3.0–24+
• Redhat Enterprise Linux:
• CoreOS: v4.19.84+

該錯誤????https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=763a9ec06c4????已被修復并合并到運行 4.19 或更高版本的 Linux 發行版的內核中。

但是，在閱讀kubernetes issue時????https://github.com/kubernetes/kubernetes/issues/67577????，我們可以看到各種 Linux 項目一直在引用這個 issue，所以我猜一些 Linux 發行版仍然存在這個 bug，并且正在努力整合修復。

如果你的 Linux 發行版的內核版本低于 4.19，我建議你為你的節點升級到最新的 Linux 發行版，但無論如何，你應該嘗試移除 CPU 限制并查看是否有任何限制.

6. 總結

監控你的容器，是否因為 throttle 而導致的性能不佳，如果確實發生了，最好通過分批升級內核版本解決，如果無法升級，可以通過方式解決：

解除限制（個人覺得這個并不是一個好主意）

• 有性能要求的 Pod 調度到帶特定污點的節點；
• 對這些 Pod 刪除 CPU 限制，可以考慮在 namespace 級別添加限制。

增加資源

另外 CPU throttle 節流主要是因為 CPU 限制較低。它的限制影響 Cgroup 的行為。因此，一個快速解決該問題的方法是根據監控將限值提高 10-25%，以確保降低峰值或完全避免峰值。

自動擴容

因為將 CPU 請求和限制設置為相同的值通常會給人們他們所期望的行為，解決此問題的簡單方法是將 CPU 請求和限制設置為相同的值并添加 HPA。讓 Pod 根據負載進行自動擴縮容。