編者按：讓人讨厭的 CPU 限流影響容器運作，有時人們不得不犧牲容器部署密度來避免 CPU 限流出現。本文介紹的 CPU Burst 技術可以幫助您既能保證容器運作服務品質，又不降低容器部署密度。文章分為上下兩篇，該文為上篇，下篇将剖析使用 CPU Burst 和其他避免限流手段的差別，以及如何配置 CPU Burst 功能以達到最佳效果。
在 K8S 容器排程中，容器的 CPU 資源上限是由 CPU limits 參數指定。設定 CPU 資源上限可以限制個别容器消耗過多的 CPU 運作時間，并確定其他容器拿到足夠的 CPU 資源。CPU limits 限制在 Linux 核心中是用 CPU Bandwidth Controller 實作的，它通過 CPU限流限制 cgroup 的資源消耗。是以當一個容器中的程序使用了超過 CPU limits 的資源的時候，這些程序就會被 CPU 限流，他們使用的 CPU 時間就會受到限制，程序中一些關鍵的延遲名額就會變差。
面對這種情況，我們應該怎麼辦呢？一般情況下，我們會結合這個容器日常峰值的 CPU 使用率并乘以一個相對安全的系數來設定這個容器的 CPU limits ，這樣我們既可以避免容器因為限流而導緻的服務品質變差，同時也可以兼顧 CPU 資源的利用。舉個簡單的例子，我們有一個容器，他日常峰值的 CPU 使用率在 250% 左右，那麼我們就把容器 CPU limits 設定到 400% 來保證容器服務品質，此時容器的 CPU 使用率是 62.5%（250%/400%）。
然而生活真的那麼美好麼？顯然不是！CPU 限流的出現比預期頻繁了很多。怎麼辦？似乎看上去我們隻能繼續調大 CPU limits 來解決這個問題。很多時候，當容器的 CPU limits 被放大 5~10 倍的時候，這個容器的服務品質才得到了比較好的保障，相應的這時容器的總 CPU 使用率隻有 10%~20%。是以為了應對可能的容器 CPU 使用高峰，容器的部署密度必須大大降低。
曆史上人們在 CPU Bandwidth Controller 中修複了一些 BUG 導緻的 CPU 限流問題，我們發現目前非預期限流是由于100ms級别CPU突發使用引起，并且提出 CPU Burst 技術允許一定的 CPU 突發使用，避免平均 CPU 使用率低于限制時的 CPU 限流。在雲計算場景中，CPU Burst 技術的價值有：
- 不提高 CPU 配置的前提下改善 CPU 資源服務品質；
- 允許資源所有者不犧牲資源服務品質降低CPU資源配置，提升CPU資源使用率；
- 降低資源成本（TCO, Total Cost of Ownership）。
你看到的CPU使用率不是全部真相
秒級 CPU 使用率不能反映 Bandwidth Controller 工作的 100ms 級别 CPU 使用情況，是導緻非預期 CPU 限流出現的原因。
Bandwidth Controller 适用于 CFS 任務，用 period 和 quota 管理 cgroup 的 CPU 時間消耗。若 cgroup 的 period 是 100ms quota 是 50ms，cgroup 的程序每 100ms 周期内最多使用 50ms CPU 時間。當 100ms 周期的 CPU 使用超過 50ms 時程序會被限流，cgroup 的 CPU 使用被限制到 50% 。
CPU 使用率是一段時間内 CPU 使用的平均，以較粗的粒度統計 CPU 的使用需求，CPU 使用率趨向穩定；當觀察的粒度變細，CPU 使用的突發特征更明顯。以 1s 粒度和 100ms 粒度同時觀測容器負載運作，當觀測粒度是 1s 時 CPU 使用率的秒級平均在 250% 左右，而在 Bandwidth Controller 工作的 100ms 級别觀測 CPU 使用率的峰值已經突破 400% 。
根據秒級觀察到的 CPU 使用率 250% 設定容器 quota 和 period 分别為 400ms 和 100ms ，容器程序的細粒度突發被 Bandwidth Controller 限流，容器程序的 CPU 使用受到影響。
如何改善
我們用 CPU Burst 技術來滿足這種細粒度 CPU 突發需求，在傳統的 CPU Bandwidth Controller quota 和 period 基礎上引入 burst 的概念。當容器的 CPU 使用低于 quota 時，可用于突發的 burst 資源累積下來；當容器的 CPU 使用超過 quota，允許使用累積的 burst 資源。最終達到的效果是将容器更長時間的平均 CPU 消耗限制在 quota 範圍内，允許短時間内的 CPU 使用超過其 quota。
如果用 Bandwidth Controller 算法來管理休假，假期管理的周期（period）是一年，一年裡假期的額度是 quota ，有了 CPU Burst 技術之後今年修不完的假期可以放到以後來休了。
使用 CPU Burst 之後
在容器場景中使用 CPU Burst 之後，測試容器的服務品質顯著提升。觀察到 RT 均值下降 68%（從 30+ms 下降到 9.6ms ）；99% RT 下降 94.5%（從 500+ms 下降到 27.37ms ）。
如果容器運作負載是延遲敏感類型，又有配置 quota 引起的 CPU 限流，不妨試試使用 CPU Burst 技術對延遲進行優化。CPU Burst 修改已合入 Linux 5.14，Alibaba Cloud Linux 也已經支援 CPU Burst 技術。
關于作者
常懷鑫（一齋），阿裡雲核心組工程師，擅長CPU排程領域。
加入龍蜥社群
加入微信群：添加社群助理-龍蜥社群小龍（微信：openanolis_assis），備注【龍蜥】拉你入群；加入釘釘群：可掃碼或搜釘釘群号（33311793）。歡迎開發者/使用者加入龍蜥OpenAnolis社群交流，共同推進龍蜥社群的發展，一起打造一個活躍的、健康的開源作業系統生态！
龍蜥社群_小龍 釘釘群二維碼
關于龍蜥社群
龍蜥社群是由企事業機關、高等院校、科研機關、非營利性組織、個人等按照自願、平等、開源、協作的基礎上組成的非盈利性開源社群。龍蜥社群成立于2020年9月，旨在建構一個開源、中立、開放的Linux上遊發行版社群及創新平台。
短期目标是開發Anolis OS作為CentOS替代版，重新建構一個相容國際Linux主流廠商發行版。中長期目标是探索打造一個面向未來的作業系統，建立統一的開源作業系統生态，孵化創新開源項目，繁榮開源生态。
加入我們，一起打造面向未來的開源作業系統！
Https：//openanolis.cn