回到 2016 年，我們在 Buffer ，現在大約 60 個節點（在 AWS 上）和 1500 個容器正在我們的 k8s 叢集上運行，由 。 然而，我們透過反覆試驗轉向微服務，即使在使用 k8s 幾年之後，我們仍然面臨新的問題。 在這篇文章中我們將討論 處理器限制：為什麼我們認為它們是好的實踐以及為什麼它們最終不是那麼好。
處理器限制和限制
與許多其他 Kubernetes 用戶一樣， 。 如果沒有這樣的設置，節點中的容器可能會佔用所有處理器能力，進而導致重要的 Kubernetes 進程（例如 kubelet）將停止回應請求。 因此，設定 CPU 限制是保護節點的好方法。
處理器限制將容器設定為在特定時間段內可以使用的最大 CPU 時間（預設為 100 毫秒），且容器永遠不會超過此限制。 在 Kubernetes 中 節流 容器並防止其超出限制，使用專用工具 ，但這些人為的 CPU 限制最終會損害效能並增加容器的反應時間。
如果我們不設定處理器限制會發生什麼？
不幸的是，我們自己也不得不面對這個問題。 每個節點都有一個行程負責管理容器 kubelet，然後他停止回應請求。 當這種情況發生時，節點將進入狀態 NotReady，並且其中的容器將被重定向到其他地方，並在新節點上產生相同的問題。 至少可以說，這不是一個理想的情況。
節流問題的表現及回應
貨櫃追蹤的關鍵指標是 trottling，它顯示您的容器已被限制的次數。 我們感興趣地註意到某些容器中存在節流，無論處理器負載是否極端。 作為範例，讓我們來看看我們的主要 API 之一：
如下所示，我們將限制設為 800m （0.8或80%核心），且峰值最好達到 200m （20% 核心）。 看起來在限制服務之前我們仍然有足夠的處理器能力，但是...
您可能已經注意到，即使處理器負載低於指定限制（明顯低於限制），仍然會發生限制。
面對這個，我們很快就發現了幾個資源（, , ）關於由於限制導致的服務性能和響應時間下降。
為什麼我們會在低 CPU 負載時看到節流？ 簡短的版本是：“Linux 核心中存在一個錯誤，會導致對具有指定處理器限制的容器進行不必要的限制。” 如果您對問題的本質感興趣，可以閱讀簡報（ и 選項），作者：Dave Chiluk。
消除 CPU 限制（極度謹慎）
經過長時間的討論，我們決定取消所有直接或間接影響使用者關鍵功能的服務的處理器限制。
這個決定並不容易，因為我們非常重視叢集的穩定性。 過去，我們已經嘗試過我們的叢集不穩定，然後服務消耗了太多資源並減慢了整個節點的工作速度。 現在一切都有些不同了：我們清楚地了解了我們對集群的期望，以及實施計劃變更的良好策略。
關於緊迫問題的商業信函。
當限制解除時如何保護您的節點？
隔離「不受限制」的服務：
過去，我們已經看到一些節點進入某種狀態 notReady，主要是由於服務消耗了太多資源。
我們決定將此類服務放置在單獨的（「標記」）節點中，以便它們不會幹擾「相關」服務。 因此，透過標記一些節點並向「不相關」的服務添加容忍參數，我們實現了對叢集的更大控制，並且更容易識別節點的問題。 要自己執行類似的過程，您可以熟悉 .
分配正確的處理器和記憶體請求：
我們最擔心的是該過程會消耗太多資源並且節點將停止回應請求。 從現在開始（感謝 Datadog），我們可以清楚地監控叢集上的所有服務，我分析了我們計劃指定為「不相關」的服務的幾個月運行情況。 我只是將最大 CPU 使用率設為 20%，從而在節點中分配空間，以防 k8s 嘗試將其他服務分配給該節點。
如圖所示，處理器的最大負載已達到 242m CPU 核心（0.242 個處理器核心）。 對於處理器要求，取比該值稍大的數字就足夠了。 請注意，由於服務以用戶為中心，因此峰值負載值與流量一致。
對記憶體使用和查詢執行相同的操作，瞧 - 您已全部設定完畢！ 為了提高安全性，您可以新增水平 Pod 自動縮放。 因此，每次資源負載較高時，自動縮放都會建立新的 pod，kubernetes 會將它們分發到有可用空間的節點。 如果叢集本身沒有剩餘空間，您可以為自己設定警報或透過自動縮放配置新增節點。
在缺點中，值得注意的是我們輸給了“「， IE。 一個節點上運行的容器數量。 在低流量密度下我們也可能有很多“放鬆”，並且您也有可能達到高處理器負載，但自動縮放節點應該有助於後者。
Результаты
我很高興發布過去幾週實驗的出色結果；我們已經看到所有修改後的服務的回應有了顯著改進：
我們在主頁上取得了最好的成績（），服務加速 二十二次！
Linux核心bug修復了嗎？
是的， 發行版本 4.19 及更高版本。
然而，讀完後 2020 年 XNUMX 月 XNUMX 日 我們仍然會提到一些具有類似 bug 的 Linux 專案。 我相信一些 Linux 發行版仍然存在這個錯誤，並且正在努力修復它。
如果您的發行版本低於 4.19，我建議更新到最新版本，但無論如何您應該嘗試刪除處理器限制並查看限制是否仍然存在。 下面您可以看到 Kubernetes 管理服務和 Linux 發行版的部分清單：
- Debian：修復整合到最新版本的發行版中， ，而且看起來很新鮮（）。 某些先前的版本也可能已修復。
- Ubuntu：修復已整合到最新版本
- EKS 已修復 。 如果您的版本低於此版本，您應該更新 AMI。
- 科普斯： у
kops 1.18+主要主機映像將是 Ubuntu 20.04。 如果您的 kops 版本較舊，您可能需要等待修復。 我們自己現在也在等待。 - GKE（Google Cloud）：修復集成 ，但是節流有問題 .
如果修復解決了節流問題該怎麼辦？
我不確定問題是否已完全解決。 當我們到達包含修復程序的內核版本時，我將測試叢集並更新帖子。 如果有人已經更新，我有興趣閱讀您的結果。
結論
- 如果您在 Linux 下使用 Docker 容器（無論是 Kubernetes、Mesos、Swarm 或其他），您的容器可能會因節流而損失效能；
- 嘗試更新到您的發行版的最新版本，希望該錯誤已修復；
- 消除處理器限制可以解決問題，但這是一種危險的技術，應極其謹慎地使用（最好先更新核心並比較結果）；
- 如果您取消了 CPU 限制，請仔細監控您的 CPU 和記憶體使用情況，並確保您的 CPU 資源超出您的消耗；
- 一個安全的選擇是在硬體負載較高的情況下自動縮放 Pod 以建立新的 Pod，以便 Kubernetes 將它們指派給空閒節點。
我希望這篇文章可以幫助您提高容器系統的效能。
聚苯乙烯 作者與讀者和評論員通信（英文）。
來源： www.habr.com